J’ai donc une sauvegarde Discourse de notre serveur initial et nous essayons de déplacer le système vers un nouveau système.
Malheureusement, il y a deux problèmes :
Lors de la restauration, il est indiqué que 71 des 1073 téléchargements n’ont pas été migrés vers S3, ce qui entraîne un échec lors du processus de restauration.
En tentant de résoudre ce problème sur l’instance principale en rebakant, etc. les publications, il est indiqué que certains téléchargements ne sont toujours pas migrés vers S3, même lorsque j’essaie d’utiliser le mécanisme de rake uploads:migrate_to_s3.
Existe-t-il un moyen quelconque d’obtenir des informations détaillées de migrate_to_s3 sur les téléchargements qui ne sont pas migrés, afin que je puisse les corriger manuellement ? Il est également possible qu’ils fassent référence à un dépôt S3 mort/en échec d’où nous téléchargeions initialement, sauf que les choses ont explosé à ce moment-là et nous avons simplement changé de mécanisme S3 (vers MinIO bien sûr), et il y avait encore de vieilles choses dans le côté AWS S3. Ce que je ne pense pas pouvoir migrer facilement vers mon instance MinIO.
Alternativement, existe-t-il un moyen de désactiver le vérificateur de téléchargements sur S3 du mécanisme de restauration car j’ai déjà forcé la migration des téléchargements moi-même ?
OK, j’ai trouvé après avoir plongé en profondeur dans la base de données. Il semble que des restes (71 téléchargements) de l’environnement S3 d’origine, qui n’est plus utilisé depuis longtemps (ou plutôt, dans ce cas, un environnement S3 disponible mais pas principalement utilisé, car il n’était pas rentable).
J’ai fini par faire ceci :
Depuis le serveur d’origine :
./launcher enter app
sudo -u postgres psql discourse
SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%'
(remplacez ExpectedS3DomainGoesHere par l’URL réelle que vous utilisez pour votre configuration S3)
Cela vous donnera les URL avec lesquelles travailler, car nous devons faire certaines choses.
Lorsque les URL proviennent d’anciens buckets sur des URL différentes, utilisez le client Amazon S3 (ou le client de votre backend de stockage S3), et :
a. Synchronisez les buckets aux URL inattendues, si disponibles, vers le stockage local.
b. Synchronisez les éléments du local vers le nouveau bucket.
Bien qu’il ait été suggéré ici d’utiliser DbHelper.remap, la fonction remap de discourse a bien fonctionné.
Assurez-vous que les données sont migrées.
rails uploads:migrate_to_s3
Temps de rebâtir !
rails posts:rebake
Sauvegardez à nouveau le site sur la machine/le serveur d’origine. Téléchargez cette dernière mise à jour.
Depuis le nouveau serveur de destination :
Configurez Discourse comme prévu, copiez app.yml et autres du serveur d’origine vers le nouveau serveur dans /var/discourse/containers/ pour vous assurer que la reconstruction utilise les bons plugins, etc. nécessaires.
Assurez-vous de commenter toutes les entrées DISCOURSE_BACKUP_LOCATION: s3 dans app.yml, si vous travaillez avec des copies de sauvegarde locales. J’ai eu quelques problèmes avec S3 qui était bizarre avec des fichiers de sauvegarde tronqués, j’ai donc opté pour l’approche locale pour une restauration.
Suivez les étapes dans Restore a backup from the command line pour importer la sauvegarde sur votre serveur et la restaurer. Y compris les étapes de reconstruction.
Cela a été douloureux pour moi à résoudre, mais cela a été résolu une fois que j’ai plongé dans la table des téléchargements de la base de données. MAIS, cela semble avoir fonctionné, donc…
Ce qui fonctionne souvent dans ce genre de situations est de désactiver temporairement les téléchargements S3 sur l’instance d’origine avant de faire une sauvegarde. Après la restauration, vous pouvez réactiver S3.