Restaurer sur un nouvel hôte

J’ai configuré un nouvel hôte pour avoir un environnement de ‘staging’. J’ai recréé la même installation de Discourse avec ce qui devrait être la même version. J’utilise la version : 2.8.2.

Premier commentaire, à partir de la version 2.8.2, la taille de ma sauvegarde est passée de 282 Mo à environ 90 Mo. Je ne sais pas pourquoi, mais je vais continuer avec une certaine intelligence ajoutée dont je profite.

J’ai téléchargé la dernière archive de mon forum et l’ai téléchargée sur le stockage local du nouvel environnement de staging.

La restauration échoue en raison de :

[2022-02-27 19:41:18] ALTER TABLE
[2022-02-27 19:41:18] ALTER TABLE
[2022-02-27 19:41:18] Migration de la base de données...
[2022-02-27 19:43:00]
[2022-02-27 19:43:00] Reconnexion à la base de données...
[2022-02-27 19:43:00] Rechargement des paramètres du site...
[2022-02-27 19:43:00] Désactivation des e-mails sortants pour les utilisateurs non-staff...
[2022-02-27 19:43:02] Désactivation du mode lecture seule...
[2022-02-27 19:43:02] Nettoyage du cache des catégories...
[2022-02-27 19:43:02] Rechargement des traductions...
[2022-02-27 19:43:02] Remappage des téléchargements...
[2022-02-27 19:43:02] Remappage de 'https://forum.geekbeacon.org' vers 'https://forum-staging.geekbeacon.org'
[2022-02-27 19:43:08] Restauration des téléchargements, cela peut prendre un certain temps...
[2022-02-27 19:43:36] EXCEPTION : 8 messages n'ont pas été remappés vers la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données 'default'.
[2022-02-27 19:43:36] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:87:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:317:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:62:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:44:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:61:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:23:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:36:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2022-02-27 19:43:36] Tentative de rollback...
[2022-02-27 19:43:36] Rollback en cours...
[2022-02-27 19:43:36] Nettoyage...
[2022-02-27 19:43:36] Suppression des fonctions du schéma discourse_functions...
[2022-02-27 19:43:36] Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2022-02-27-194051'...
[2022-02-27 19:43:36] Réactivation de Sidekiq...
[2022-02-27 19:43:36] Marquage de la restauration comme terminée...
[2022-02-27 19:43:36] Notification à 'csgeek' de la fin de la restauration...

1 « J'aime »

C’est votre problème. Peut-être utiliser le même compartiment S3 et utiliser le même compartiment ? Peut-être vérifier que le paramètre caché appelé quelque chose comme « télécharger S3 dans la sauvegarde » est activé. Vous devrez rechercher ou regarder dans la source le nom du paramètre.

Ou peut-être devez-vous vérifier que le reste de vos téléchargements sur le site de production sont sur S3.

1 « J'aime »

Je n’ai pas de S3 configuré, je suppose que l’ancien serveur a peut-être des données anciennes qui n’ont pas été mappées à un emplacement S3 valide.

Je suis retourné sur l’ancien serveur et j’ai 2 buckets configurés, 1 pour les sauvegardes et 1 pour les médias. J’ai suivi le guide et configuré AWS S3, y compris le CDN.

Lorsque j’exécute rake uploads:migrate_to_s3, qui a échoué, j’ai suivi cela avec un posts:rebake et cela semble avoir réduit le nombre d’erreurs, mais cela échoue toujours :

Veuillez noter que la migration vers S3 n'est actuellement pas réversible !
[CTRL+c] pour annuler, [ENTRÉE] pour continuer

Migration des téléchargements vers S3 pour 'default'...
Téléchargement des fichiers vers S3...
 - Listage des fichiers locaux
 => 208 fichiers
 - Listage des fichiers S3
. => 978 fichiers
 - Synchronisation des fichiers vers S3
................................................................................................................................................................................................................
Mise à jour des URL dans la base de données...
Suppression des anciennes images optimisées...
Marquage de tous les posts contenant des lightboxes pour re-cuisson...
15 posts ont été marqués pour une re-cuisson
rake avorté !
FileStore::ToS3MigrationError: 1 posts ne sont pas remappés à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données 'default'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:87:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:123:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:102:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:90:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:100:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:96:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tâches : TOP => uploads:migrate_to_s3
(Voir la trace complète en exécutant la tâche avec --trace)

Y a-t-il un moyen d’exécuter migrate_to_s3 en mode verbeux pour identifier le post fautif ?

J’ai le même problème, en migrant mon serveur sans changer le bucket s3.
Des suggestions ?

Votre restauration échoue avec une erreur de ce type ?

FileStore::ToS3MigrationError: 1 publications ne sont pas remappées à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données 'default'.

Dans ce cas, la meilleure chose à faire est de corriger la ou les publications dont les téléchargements se trouvent au mauvais endroit. Mais je pense qu’il existe un cas où ce test peut avoir un faux positif. Dans ce cas, vous pouvez utiliser un commutateur sur la tâche rake qui la mettra en pause afin que vous puissiez régler les problèmes. Je ne le trouve pas rapidement, et il n’est pas à Backup discourse from the command line où il devrait être. Je suis en pleine tâche, donc je ne peux pas le trouver maintenant.

Oui, j’ai ce type d’erreur

EXCEPTION: 3 messages n’ont pas été remappés à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données ‘default’

Vous pouvez essayer

discourse restore --pause filename

Cela mettra la restauration en pause et vous pourrez tripoter la base de données dans un autre terminal pour la corriger. Ou, je crois, vous pouvez simplement l’arrêter avant qu’elle n’effectue cette vérification.

Je dois utiliser ceci pendant une restauration en ligne de commande, je pense

Même erreur :
Téléchargement des fichiers vers S3…

  • Liste des fichiers locaux
    => 2 fichiers
  • Liste des fichiers S3
    … => 183549 fichiers
  • Synchronisation des fichiers vers S3
    ..
    Mise à jour des URL dans la base de données…
    Suppression des anciennes images optimisées…
    Signalement de tous les messages contenant des lightboxes pour re-cuisson (rebake)…
    169809 messages ont été signalés pour une re-cuisson
    EXCEPTION : 3 messages ne sont pas remappés à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données ‘default’.
    /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in raise_or_log' /var/www/discourse/lib/file_store/to_s3_migration.rb:81:in migration_successful?’
    /var/www/discourse/lib/file_store/to_s3_migration.rb:385:in migrate_to_s3' /var/www/discourse/lib/file_store/to_s3_migration.rb:59:in migrate’
    /var/www/discourse/lib/file_store/s3_store.rb:367:in copy_from' /var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in restore_uploads’
    /var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in restore' /var/www/discourse/lib/backup_restore/restorer.rb:179:in restore_uploads’
    /var/www/discourse/lib/backup_restore/restorer.rb:72:in run' script/discourse:243:in restore’
    /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in run' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in invoke_command’
    /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/base.rb:584:in start’
    script/discourse:397:in \u003ctop (required)\u003e’ /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in load’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in kernel_load' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:23:in run’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:452:in exec' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/command.rb:28:in run’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in invoke_command' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor.rb:538:in dispatch’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:35:in dispatch' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/base.rb:584:in start’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:29:in start' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:28:in block in \u003ctop (required)\u003e’
    /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/friendly_errors.rb:117:in with_friendly_errors' /usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:20:in \u003ctop (required)\u003e’
    /usr/local/bin/bundle:25:in load' /usr/local/bin/bundle:25:in
    Tentative de retour arrière…
    Retour arrière en cours…
    Nettoyage…
    Suppression des fonctions du schéma discourse_functions…
    Suppression du répertoire tmp ‘/var/www/discourse/tmp/restores/default/2026-01-13-145033’…
    Réactivation de sidekiq…
    Marquage de la restauration comme terminée…
    Notification à ‘system’ de la fin de la restauration…
    Terminé !

Vous devez soit corriger ces trois téléchargements, soit arrêter la restauration avant qu’elle n’effectue cette vérification.

Comment pourrais-je trouver
3 publications sur 168000 ?
Est-il possible d’arrêter la restauration, en sautant cette vérification ?

Je regarderais le code qui effectue ce test, puis j’exécuterais la même requête. J’ai peut-être déjà publié le code pour le faire.

J’ai publié

L’avez-vous fait ? Je pense que vous pourriez simplement faire un contrôle-c après qu’il ait terminé la restauration. Faites-vous une restauration uniquement de la base de données ?

Oh zut, je n’avais pas pensé à arrêter la restauration après la base de données et avant les téléchargements.
Je n’ai pas besoin de déplacer les téléchargements depuis S3 — puis-je simplement migrer le frontend et la base de données ?

Pouvez-vous me dire quelle option permet d’arrêter le rake sur les publications et d’identifier celles qui posent problème ? Cela serait grandement apprécié.

Des suggestions ? Merci