Je rencontre des problèmes lors de la tentative de restauration de notre instance Discourse de préproduction. La version de préproduction est v2.4.0.beta1 +36. Avez-vous une idée de l’origine du problème ou des pistes à explorer ? Merci d’avance !
Voici la fin de la sortie du journal :
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migration de la base de données...
[2019-07-16 20:08:16] Reconnexion à la base de données...
[2019-07-16 20:08:16] Rechargement des paramètres du site...
[2019-07-16 20:08:16] Désactivation des e-mails sortants pour les utilisateurs non membres du personnel...
[2019-07-16 20:08:16] Vidage du cache des emojis...
[2019-07-16 20:08:16] Désactivation du mode lecture seule...
[2019-07-16 20:08:16] Vidage du cache des thèmes
[2019-07-16 20:08:22] Extraction des pièces jointes...
[2019-07-16 20:08:40] Migration des pièces jointes vers S3...
[2019-07-16 20:08:46] Le processus de restauration a été annulé !
[2019-07-16 20:08:46] Tentative de retour en arrière...
[2019-07-16 20:08:46] Retour en arrière en cours...
[2019-07-16 20:08:47] Nettoyage...
[2019-07-16 20:08:47] Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2019-07-16-200516'...
[2019-07-16 20:08:48] Reprogrammation de sidekiq...
[2019-07-16 20:08:48] Marquage de la restauration comme terminée...
Ci-dessous se trouve la sortie après l’exécution de discourse restore BACKUP_FILENAME depuis la ligne de commande. Tout retour est apprécié, merci !
Désactivation des e-mails sortants pour les utilisateurs non membres du personnel...
Vidage du cache des emojis...
Désactivation du mode lecture seule...
Vidage du cache du thème
Extraction des fichiers joints...
Migration des fichiers joints vers S3...
Vérification si la migration par défaut a déjà été effectuée...
524 des 9474 fichiers joints n'ont pas été migrés vers S3. Échec de la migration S3 pour la base de données 'default'.
321 messages n'ont pas été réaffectés à la nouvelle URL de fichier joint S3. Échec de la migration S3 pour la base de données 'default'.
Recherche des fichiers joints manquants sur : default
Correction des fichiers joints manquants :
..........................................................................................................
116 fichiers joints de messages sont manquants.
116 fichiers joints sont manquants.
106 des 116 fichiers joints utilisent l'ancien schéma.
98 des 83342 messages sont concernés.
rake posts:missing_uploads a identifié 98 problèmes. Échec de la migration S3 pour la base de données 'default'.
Aucun message ne nécessite de régénération
Migration des fichiers joints vers S3 pour 'default'...
Certains fichiers joints n'ont pas été migrés vers le nouveau schéma. Veuillez exécuter ces commandes dans la console Rails
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
Le processus de restauration a été annulé !
Tentative d'annulation...
Annulation en cours...
Nettoyage...
Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2019-07-22-172918'...
Reprendre sidekiq...
Marquer la restauration comme terminée...
Notification à 'system' de la fin de la restauration...
Terminé !
[ÉCHEC]
Restauration terminée.
Non, ce n’est pas encore corrigé. Cependant, en attendant, vous pouvez désactiver temporairement le paramètre du site enable_s3_uploads avant de créer la sauvegarde.
Je suis presque certain que je viens d’être touché par ce problème aussi ; je pense que cela devrait être signalé comme un bug.
(Si c’est différent, n’hésitez pas à créer un nouveau sujet séparé).
Il est plutôt important que la restauration des sauvegardes fonctionne.
Notez que la raison de l’échec n’est pas évidente lorsque vous utilisez l’interface d’administration et cliquez sur Restaurer à côté du nom de la sauvegarde ; vous obtenez :
...
Migration des pièces jointes vers S3...
Le processus de restauration a été annulé !
...
L’exécution de la restauration via la ligne de commande vous donne plus de détails :
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconnexion à la base de données...
Rechargement des paramètres du site...
Désactivation des emails sortants pour les utilisateurs non membres du personnel...
Vidage du cache des emojis...
Désactivation du mode lecture seule...
Vidage du cache du thème
Extraction des pièces jointes...
Remappage des pièces jointes...
Remappage de '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' vers '/uploads/default/'
optimized_images=3
uploads=1
Migration des pièces jointes vers S3...
Vérification si la migration par défaut a déjà été effectuée...
6 des 12 pièces jointes n'ont pas été migrées vers S3. Échec de la migration S3 pour la base de données 'default'.
1 publication n'a pas été remappée vers la nouvelle URL de pièce jointe S3. Échec de la migration S3 pour la base de données 'default'.
Recherche des pièces jointes manquantes sur : default
0 pièces jointes de publication sont manquantes.
Veuillez fournir les variables d'environnement suivantes :
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
et soit
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
ou
- DISCOURSE_S3_USE_IAM_PROFILE
Le processus de restauration a été annulé !
Tentative de retour en arrière...
Retour en arrière...
Nettoyage des éléments...
Suppression de la fonction du schéma discourse_functions
Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Reprise de sidekiq...
Marquage de la restauration comme terminée...
Notification à 'system' de la fin de la restauration...
Terminé !
[ÉCHEC]
Restauration terminée.
J’ai ajouté un peu de code de débogage dans uploads.rake juste avant « Veuillez fournir les variables d’environnement suivantes » pour afficher les variables d’environnement :
puts "ENV: " + ENV.inspect
ENV ne contenait aucune variable DISCOURSE_S3_* définie.
Y a-t-il une raison valable pour laquelle ces données ne sont pas extraites des paramètres ?
Je pense que l’idée est que si vous avez des fichiers uploadés sur S3, vous effectuerez une sauvegarde uniquement de la base de données, et cela ne risque pas d’échouer car il n’y aura pas de fichiers uploadés à inclure.
Tout à fait, mais cela ne aide pas quand la sauvegarde que vous avez inclut les téléchargements.
Pour être clair - ce n’est pas critique pour moi en ce moment, je peux commenter les lignes problématiques et terminer la restauration, mais d’autres ne le peuvent pas.
Inutile de le convertir en bug. C’est dans mes attributions et j’ai déjà consacré énormément de temps à la refactorisation du processus de restauration, à l’ajout de nombreux tests et à l’amélioration de sa fiabilité. Je vais apporter quelques ajustements supplémentaires pour réduire les risques de rupture lors de la restauration vers S3 et pour afficher plus d’informations dans l’interface d’administration.
À ma connaissance, la fonctionnalité de sauvegarde/restauration a été refaite, mais je viens de découvrir que ce problème persiste.
Une tentative de restauration sur beta11 d’une sauvegarde avec l’option enable s3 uploads activée échoue toujours avec :
[2020-02-18 09:51:38] Restauration des fichiers joints, cela peut prendre un certain temps...
[2020-02-18 09:51:38] EXCEPTION : Veuillez fournir les variables d'environnement suivantes :
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
et soit
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
soit
- DISCOURSE_S3_USE_IAM_PROFILE
[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
C’est exact, il s’agit d’une migration des téléversements.
Les identifiants d’accès S3 sont présents dans la base de données restaurée, il n’est donc pas nécessaire de les exiger également dans une variable d’environnement.
La fourniture des variables d’environnement entraîne également un échec :
Restauration des téléversements, cela peut prendre un certain temps...
Vérification si db8015 a déjà été migré...
200 des 206 téléversements n'ont pas été migrés vers S3. Échec de la migration S3 pour la base de données 'db8015'.
5 publications n'ont pas été remappées vers la nouvelle URL de téléversement S3. Échec de la migration S3 pour la base de données 'db8015'.
Aucune publication ne nécessite de remoulage.
Migration des téléversements vers S3 pour 'db8015'...
Téléversement des fichiers vers S3...
- Répertorier les fichiers locaux
=> 21 fichiers
- Répertorier les fichiers S3
. => 16 fichiers
- Synchronisation des fichiers vers S3
.....................
Mise à jour des URL dans la base de données...
Suppression des anciennes images optimisées...
Marquage de toutes les publications contenant des lightboxes pour un remoulage...
5 publications ont été marquées pour un remoulage
EXCEPTION : 183 des 206 téléversements n'ont pas été migrés vers S3. Échec de la migration S3 pour la base de données 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'
Je ne sais pas pourquoi cela échoue.
La plupart des téléversements étaient déjà sur S3, donc les messages « 200 des 206 téléversements n’ont pas été migrés vers S3 » et « 183 des 206 téléversements n’ont pas été migrés vers S3 » sont incorrects. Le nombre de 21 fichiers locaux est correct, et il y a environ 200 téléversements sur S3 (cela pourrait être 206 également). Je ne reconnais aucun des autres chiffres (183, 16).
Je ne sais pas non plus pourquoi le processus de restauration tente de déplacer davantage de téléversements vers S3 ? Il devrait simplement prendre les images locales de la sauvegarde et laisser les téléversements sur S3 tels quels ? Ou est-ce que je passe à côté de quelque chose ?
Finalement, j’ai fini par modifier manuellement le paramètre enable_s3_uploads dans le dump de la base de données pour le mettre à false, mais cela a entraîné le remappage de tout vers le stockage local. Et comme quelques images étaient encore locales, il a fallu beaucoup de travail pour déterminer lesquelles devaient être remappées vers S3 et lesquelles ne devaient pas l’être.
Le mélange des uploads locaux avec ceux stockés sur S3 n’est pas pris en charge. Oui, je sais, il est possible de se retrouver dans une telle situation lorsqu’un utilisateur passe du stockage local à S3 sans migrer les uploads existants vers S3, mais c’est une autre histoire…
La restauration d’une sauvegarde inclut toujours la réorientation des uploads si le système détecte des modifications affectant les URL des uploads. Cela inclut le passage du mode standalone au multisite, le passage des uploads locaux à S3, ainsi que les modifications des paramètres S3 et CDN. Tous les uploads sont restaurés à l’emplacement correct selon les paramètres, soit localement, soit sur S3.
De temps en temps, nous rencontrons des sauvegardes où la réorientation automatique et la migration vers S3 échouent pour diverses raisons. Vous pouvez vous attendre à voir davantage d’améliorations au début du cycle de développement de la version 2.5.