Implosion après la mise à niveau 2.7beta7

Soutien
1

Bonjour à tous,

Nous exploitons une instance Discourse auto-hébergée à l’adresse https://discourse.bokeh.org depuis plusieurs années. En général, elle a été extrêmement stable et ne nécessitait presque aucun effort de maintenance ; en particulier, les mises à jour se déroulaient presque toujours sans aucun incident et s’achevaient parfaitement sans problème.

Cependant, aujourd’hui, après une mise à jour vers la version 2.7beta7 (qui semblait s’être déroulée sans problème), notre site s’est complètement effondré. Il a tenu un peu avec des pages mal rendues et des erreurs dans la console JavaScript, mais après avoir tenté un retour en arrière, l’interface utilisateur est devenue non fonctionnelle. En me connectant au droplet, j’ai également essayé, en vain :

Reconstruction

./launcher rebuild app

Cela a échoué de plusieurs manières sur plusieurs tentatives.

Discourse Doctor

./discourse-doctor

Restauration

./launcher enter app
discourse restore <fichier de sauvegarde>

Cela a échoué.

Effacement

J’ai également essayé de faire un « effacement » puis une restauration :

./launcher stop app
./launcher destroy app
rm -r /var/discourse/shared/standalone/

Après cela, j’ai au moins réussi à exécuter une reconstruction avec succès, ce qui a conduit à un état d’« installation fraîche », par exemple « Félicitations, vous avez installé Discourse ! ».

J’ai donc essayé à nouveau d’exécuter discourse restore, mais cela a encore échoué :

EXCEPTION : 1 publication n'a pas été réattribuée à 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:131:in `raise_or_log' /var/www/discourse/lib/file_store/to_s3_migration.rb:86:in `migration_successful?' /var/www/discourse/lib/file_store/to_s3_migration.rb:357:in `migrate_to_s3' /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate' /var/www/discourse/lib/file_store/s3_store.rb:240: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:62:in `run' script/discourse:145:in `restore' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/base.rb:485:in `start' script/discourse:286:in `' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `kernel_load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:28:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:494:in `exec' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:30:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:24:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:49:in `block in ' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:37:in `' /usr/local/bin/bundle:23:in `load' /usr/local/bin/bundle:23:in `' Tentative de retour en arrière... Retour en arrière en cours... Nettoyage des éléments... Suppression des fonctions du schéma discourse_functions... Suppression du répertoire temporaire '/var/www/discourse/tmp/restores/default/2021-04-23-235404'... Marquage de la restauration comme terminée... Notification au système de la fin de la restauration... Terminé ! [ÉCHEC]

Ce qui est étrange, c’est que pendant la restauration, le site semblait revenir à la normale, avec l’apparition d’anciens contenus. Puis l’échec s’est produit et maintenant rien ne s’affiche, les comptes ont disparu, etc.

Je serais vraiment reconnaissant de tout conseil ou suggestion. Nous disposons de sauvegardes quotidiennes remontant à une semaine (et plus loin dans Glacier si nécessaire). Nous avons supprimé une catégorie inutilisée il y a quelques jours ; cela pourrait-il être la cause du problème ? Je vais essayer une sauvegarde plus ancienne pour voir, mais toute indication concernant un processus de restauration infaillible serait la bienvenue.

2

Une sauvegarde plus ancienne n’a pas aidé. Pendant la restauration, tout semble « à peu près bien » :

Screen Shot 2021-04-23 at 5.20.53 PM
Screen Shot 2021-04-23 at 5.20.53 PM2382×1968 463 KB

Juste jusqu’à la fin, puis immédiatement vers ceci :

Screen Shot 2021-04-23 at 5.21.03 PM
Screen Shot 2021-04-23 at 5.21.03 PM2742×1308 179 KB

Au passage, la sauvegarde ne contient-elle pas les messages qui ont été importés à l’origine depuis une liste de diffusion, mais qui sont présents sur le site Discourse depuis des années ?? Nous avions 24 000 messages, pas 5 000, avant cela.

3

Existe-t-il un moyen de reconstruire l’application à partir d’une version antérieure de Discourse, par exemple la version 2.7beta6 ?

4

Sinon, je suppose qu’il y a littéralement un seul post qui cause un problème

EXCEPTION : 1 post n’a pas été réaffecté à la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données ‘default’.

Est-il possible de trouver ce post et de le supprimer ou de le retirer simplement ?

5

Avez-vous des images sur S3 ?

6

@pfaffman Oui, nous avons bien des images sur S3

7

Hmm. Peut-être qu’il n’y a qu’un seul message corrompu ? Je suppose qu’il faudrait restaurer la base de données, la corriger, puis reconstruire le fichier de sauvegarde avec la nouvelle base. Mais c’est vraiment difficile à dire.

8

Y a-t-il des instructions quelque part sur la façon de faire cela ? Comment puis-je identifier quel est le seul message cassé ?

Éditer : sinon, existe-t-il une personne compétente que l’on pourrait engager pour des services ?

9

Avez-vous une sauvegarde ou un instantané récent de votre droplet que vous pouvez restaurer ?

10

Avez-vous une sauvegarde de droplet récente ou une instantanée que vous pouvez restaurer ?

Malheureusement, non. Les sauvegardes de DO sont uniquement hebdomadaires et j’avais configuré des sauvegardes quotidiennes de Discourse vers S3, conservant une semaine de données récentes et un an dans Glacier. Étant donné ma précédente expérience positive avec de nombreuses mises à niveau de Discourse, je pensais que cela serait à la fois suffisant et préférable (et j’avais déjà effectué des restaurations de test réussies).

12

disons
version: 94301854938a0b36dd64666fb7a7c8406544a781 qui est le commit juste avant la mise à niveau vers la version bêta

13

En fait, une mise à jour. Dans un moment de désespoir, j’ai simplement interrompu brutalement le script de restauration pendant l’étape

Synchronisation des fichiers vers S3

, avant qu’il ne signale le 1 mauvais post et ne lance un retour en arrière.

Le site s’est en fait redémarré et était accessible en mode sans échec. J’ai désactivé le composant de thème « COPIER COLLER » pour les blocs de code qui semble désormais totalement incompatible avec la dernière version bêta. Après cela, le site semble en fait être majoritairement fonctionnel, même sans le mode sans échec. Mais :

  • Y a-t-il des actions recommandées pour s’assurer que tout est aussi « nettoyé » que possible ? Par exemple, réimporter les ressources vers S3 et « recuire » ? Où trouver les meilleures, les plus récentes instructions à ce sujet ?

EDIT : autant que je puisse en juger, tout est revenu à la normale. Les images dans les anciens posts se chargent correctement depuis S3/CDN. Je suppose donc que ma question est : si nous téléchargeons des images vers S3, cette option devrait-elle être décochée ?

Inclure les fichiers joints dans les sauvegardes planifiées. La désactivation de cette option ne sauvegardera que la base de données.

Je pensais que cocher cette option offrait une couche de redondance supplémentaire, mais il semble que ce soit la source de tous ces problèmes lors de la restauration ?

14

La dernière fois que j’ai changé de fournisseur d’hébergement, j’ai rencontré des problèmes avec S3 lors de la restauration. J’ai donc posé la question et la réponse était oui. Lorsque vous stockez vos images sur S3, vous devez effectuer la sauvegarde sans inclure les fichiers joints. Seule la base de données. Mais je ne sais pas si c’est la solution adaptée à votre cas. Si vous essayez, créez d’abord un instantané.

Vous pouvez en savoir plus ici : Restore a backup from the command line - #28

Je l’ai essayé et cela a très bien fonctionné sans aucun problème. :slightly_smiling_face:

15

Je peux vous aider. Lundi, ou plus tôt si vous acceptez une majoration pour danger.

Vous pouvez Contact Us - Literate Computing notre S3 l’adresse e-mail située en bas de la page.

16

@pfaffman Merci ! Le site semble maintenant fonctionner parfaitement, mais je ne refuserais pas un coup d’œil rapide / une vérification de bon sens à votre convenance, si vous êtes disposé. Dans tous les cas, j’ai noté vos coordonnées commerciales pour d’éventuelles urgences futures. :slight_smile:

Voici un récapitulatif, au cas où cela serait utile à d’autres personnes

RÉSUMÉ

Après une mise à jour (réussie), un plugin de composant de thème non officiel incompatible a rendu l’interface utilisateur du site cassée. Cela n’a pas été détecté à l’époque, donc le processus de restauration de sauvegarde a été lancé, mais il a rencontré des problèmes en raison d’une configuration peu optimale.

DÉTAILS

  1. Une mise à jour vers 2.7beta7 a été lancée et s’est déroulée avec succès.

  2. Cependant, après la mise à jour, l’interface utilisateur du site a été gravement compromise : les corps des publications étaient entièrement manquants, la navigation principale (y compris utilisateur / connexion) était totalement absente, et la console JS signalait des erreurs.

    1. La raison en était un composant tiers incompatible pour copier-coller des blocs de code, mais cela n’a pas été identifié à l’époque.

    2. De plus, la possibilité d’activer le mode sans échec n’était pas connue. Si cela avait été su, les problèmes restants auraient pu être évités.

  3. L’accès à \admin a été obtenu par navigation directe, et une tentative de retour en arrière a été lancée. Cela a immédiatement déconnecté l’utilisateur, et il ne semblait y avoir aucun moyen de se reconnecter avec l’interface utilisateur cassée.

  4. Connexion au Droplet DO pour lancer une restauration manuelle avec la dernière archive de sauvegarde depuis S3.

  5. De nombreuses tentatives de restauration ont échoué à l’étape finale, après le téléchargement des ressources S3, en raison d’une seule publication comportant une erreur.

    1. Cela est apparemment dû au fait que les restaurations qui tentent de re-télécharger des ressources vers S3 peuvent être instables (plusieurs rapports à ce sujet sur Meta).
    2. Cependant, il n’était pas nécessaire de sauvegarder les ressources téléversées, car elles sont déjà stockées sur S3 !

  6. Lors de l’une des nombreuses tentatives de restauration, le site a également été effacé pour repartir d’une « page blanche », de sorte que les retours en arrière après les échecs de restauration ont maintenant ramené le site à un état vide.

  7. Finalement, dans un pari désespéré, j’ai lancé la restauration et interrompu brutalement le script pendant le téléchargement S3 (juste avant l’échec et le retour en arrière).

  8. Le site est revenu en ligne, mais présentait les problèmes d’interface utilisateur précédents. Cependant, le mode sans échec était maintenant connu et utilisé, et le site fonctionnait normalement avec les plugins et thèmes désactivés.

  9. Tous les plugins et thèmes non officiels ont été supprimés (y compris le composant « copier-coller »), après quoi le site a fonctionné normalement.

  10. Vérification que les images précédemment téléversées se chargeaient toujours et provenaient bien du CDN S3.

Je soupçonne que le dernier téléchargement et la « recuisson » n’étaient pas nécessaires puisque les ressources étaient déjà présentes sur S3, et que les publications n’avaient pas besoin d’être mises à jour pour utiliser de nouvelles URL.

Je ne suis pas certain de savoir quelles étapes de restauration restantes, le cas échéant, ont été manquées après l’interruption du script, mais jusqu’à présent, personne n’a rencontré de problèmes avec le site dans son état actuel.

LEÇONS / ACTIONS

  • Commencer par le mode sans échec pour diagnostiquer les problèmes à l’avenir
  • Désactiver le paramètre incluant les téléversements dans les sauvegardes (je suggérerai à Discourse d’alerter sur cette situation)
  • Supprimer tous les plugins et composants de thème non officiels
  • Suggérer d’activer la nouvelle fonctionnalité intégrée de copie de blocs de code
  • Activer les sauvegardes d’images hebdomadaires de Digital Ocean comme filet de sécurité pour la récupération
17

Composant de thème ou plugin ? Pourriez-vous en informer l’auteur ?

18

@merefield Cela semble être connu, c’est ainsi que j’ai appris la possibilité

https://meta.discourse.org/t/copy-option-for-code-blocks-in-discourse/60961

19

Si je devais faire une suggestion concernant le processus de restauration, ce serait d’offrir des options pour le rendre plus robuste. Par exemple, si le seul obstacle à une restauration réussie est un seul message erroné, j’appuierais sur la touche Y sans hésiter si on me demandait : « Supprimer le message erroné ? »

20

Cela sera inclus dans l’une des prochaines versions bêta 2.8. Malheureusement, ce n’est pas encore prêt pour la prochaine version 2.7.

Je suis désolé de ne pas avoir vu votre appel à l’aide plus tôt. Voici un conseil pour tous ceux qui rencontrent des problèmes avec les restaurations dues à des fichiers stockés sur S3 : extrayez le fichier dump.sql.gz de votre sauvegarde et renommez-le. Par exemple, si la sauvegarde originale s’appelait discourse-2020-10-09-133921-v20201007124955.tar.gz, le fichier résultant doit être nommé discourse-2020-10-09-133921-v20201007124955.sql.gz. La restauration de ce fichier devrait fonctionner.