L’exécution de « ./launcher rebuild app » échoue sur db:migrate. Notez que nous utilisons PostgreSQL v12.
Cela a détruit notre forum. Le conteneur Docker est revenu en ligne, mais le forum non. Heureusement, j’avais pris un instantané de la VM avant la mise à niveau, je le restaure maintenant.
Journal :
Tasks : TOP => db:migrate
(Voir la trace complète en exécutant la tâche avec --trace)
I, [2022-04-14T15:20:51.896917 #1] INFO -- : == 20220304162250 EnableUnaccentExtension: migrating =========
-- enable_extension("unaccent")
I, [2022-04-14T15:20:51.897218 #1] INFO -- : Terminating async processes
I, [2022-04-14T15:20:51.897265 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 1710
I, [2022-04-14T15:20:51.897396 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1827
2022-04-14 15:20:51.897 UTC [1710] LOG: received fast shutdown request
1827:signal-handler (1649949651) Received SIGTERM scheduling shutdown...
2022-04-14 15:20:51.900 UTC [1710] LOG: aborting any active transactions
2022-04-14 15:20:51.902 UTC [1710] LOG: background worker "logical replication launcher" (PID 1719) exited with exit code 1
2022-04-14 15:20:51.904 UTC [1714] LOG: shutting down
1827:M 14 Apr 2022 15:20:51.913 # User requested shutdown...
1827:M 14 Apr 2022 15:20:51.914 * Saving the final RDB snapshot before exiting.
2022-04-14 15:20:51.965 UTC [1710] LOG: database system is shut down
1827:M 14 Apr 2022 15:20:53.157 * DB saved on disk
1827:M 14 Apr 2022 15:20:53.157 # Redis is now ready to exit, bye bye...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 2118 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
2dcd9aeca614c9e06ef748f673eb68203db6eae5c445253b416d666663879d6d
==================== END REBUILD LOG ====================
Échec de la reconstruction de l'application.
Ils ne sont pas séparés et aucun PG externe. La mise à niveau PG13 échoue également (de manière non destructive, contrairement à la mise à niveau d’aujourd’hui) et je n’ai pas reçu de support pour savoir comment la corriger ici, pour être honnête.
Je crois (je ne peux pas vérifier, évidemment) que nous n’avions qu’un seul conteneur apparaissant dans docker ps. L’installation standard comporte maintenant 2 conteneurs ?
Cette extension est devenue disponible en tant qu’extension « de confiance » sur PostgreSQL 13+, où elle peut être activée par n’importe quel utilisateur.
Étant donné que vous utilisez une version plus ancienne de PostgreSQL, vous devrez trouver une solution de contournement en installant et en activant cette extension pour l’utilisateur Discourse, et potentiellement en essayant de tromper Discourse pour qu’il considère cette extension comme déjà installée. Ou alors, passer à la version actuellement prise en charge de PostgreSQL.
OK. Pour résumer, vous ne prenez plus en charge PG12. Je suggère de publier cela dans le fil de discussion de la mise à niveau PG13 quelque part, et probablement aussi dans les annonces de 2.9.0b4.
Si vous craignez les temps d’arrêt, une solution consisterait à répliquer le serveur sur le nouvel hôte. Quelque chose comme community/archived/setting-up-postgres-hot-standby.md at master · GoogleCloudPlatform/community · GitHub. (Vous pourriez trouver des instructions plus récentes ou qui ont plus de sens pour vous…). Cela vous permettrait de migrer vers la nouvelle base de données pendant que l’ancienne continuerait de fonctionner. Mais ce n’est pas simple du tout.
C’est une idée intéressante, si c’était du mysql, du ms-sql ou de l’oracle, je le ferais, mais étant donné mon manque d’expérience avec postgres, je subirais probablement la panne.
Ma restauration s’est enfin terminée, après plus de 4 heures. Et Discourse renvoyait des erreurs 502. Ce snapshot a été pris avant la mise à niveau, donc c’est super bizarre.
En regardant les logs nginx, j’ai trouvé cette erreur :
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': cannot load such file -- /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb (LoadError)
Effectivement, ce fichier appartenait à root:root et avait les permissions 0000. Le changer en discourse:root et 644 pour correspondre aux autres fichiers de ce répertoire nous a permis de redémarrer. Ouf !
Une idée de comment ce fichier a pu être supprimé/modifié ? Il fait aussi 0 octet, c’est super étrange.
root@forum-app:/shared/log/rails# ls -la /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
-rw-r--r-- 1 discourse root 0 Feb 10 17:41 /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
J’ai essayé de faire la « restauration sur une installation propre », mais ça ne marche pas, PG ne coopère pas. J’ai essayé de rétrograder la version de Discourse et de revenir à PG12, mais alors cela devient un carnaval de lumière avec tous les plugins.
Oui, j’ai modifié le modèle, dans le cadre de la stratégie « ok, ça ne marche pas » afin de pouvoir revenir à PG12 (même si cela me fait me demander comment je vais pouvoir mettre à niveau PG alors ).
J’ai essayé des commits plus récents, mais l’erreur enable_extension("unaccent") est toujours présente, ce qui implique que sur ces commits, le changement pour en dépendre avait déjà été effectué.
J’attends le résultat de cette tentative.
Mise à jour : Non, a échoué lors de la restauration pendant la phase de « décompression du dump » et est maintenant de nouveau en panne.
Salut, si vous avez une sauvegarde de Discourse, je vous suggère d’essayer cela sur un serveur différent pour l’essayer d’abord.
Je pense que vous avez rencontré ce problème lors de la mise à niveau d’une instance de Discourse qui exécutait une ancienne version.
Alors, essayez d’installer une copie de Discourse en modifiant manuellement le fichier yml pour utiliser la version « stable » de Discourse et en épinglant la version de PostgreSQL à 12.
Si la compilation réussit, essayez de restaurer la sauvegarde. J’espère qu’elle sera restaurée avec succès.
Si cela réussit, remplacez le modèle PostgreSQL 12 par le modèle PostgreSQL par défaut et commentez la balise stable afin que Discourse soit reconstruit avec les derniers tests réussis.
Je pense que si la sauvegarde est récupérable, elle devrait alors pouvoir survivre aux mises à niveau de PostgreSQL et de Discourse.
Faites-moi savoir si vous rencontrez des problèmes.
Je suis en quelque sorte dans une impasse (“limbo”) en ce moment. J’ai essayé votre suggestion avec PG12 et “Stable”. Ça ne fonctionne pas, la restauration s’arrête simplement. Je suis donc en train de réinitialiser la machine une fois de plus pour recommencer à zéro, car maintenant elle ne veut plus faire de reconstruction d’application.
Pendant que cette machine essaie de “revenir à PG12”, j’essaie de voir si je peux avancer sur l’autre : Si j’essaie de mettre à niveau PG avec une nouvelle installation, ça échoue après Creating missing functions in the discourse_functions schema... (commence à renvoyer 500) et tail -f shared/data/log/var-log/postgres/current montre que le conteneur de données est en “mouvement”, bien qu’il soit rempli d’“erreurs” comme celle-ci :
discourse@discourse ERROR: relation "user_auth_tokens" does not exist at character 34
discourse@discourse STATEMENT: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((auth_token = 'XXXX=' OR
prev_auth_token = 'XXXX=') AND rotated_at > '2022-03-09 10:21:44.051357') LIMIT 1
discourse@discourse ERROR: relation "application_requests" does not exist at character 41
discourse@discourse STATEMENT: SELECT "application_requests"."id" FROM "application_requests" WHERE "application_requests"."date" = '2022-05-08' AND "application_requests"."req_type" = 0 LIMIT 1
Cependant, même si Discourse est planté, la machine est bien utilisée, alors… est-ce que ça fonctionne mais ça prend des heures et des heures ? Parce que j’ai laissé tourner pendant plus d’une heure et rien n’a changé.
À ce stade, je me demande déjà si cela ne devrait pas aller ici, lol.
PS : J’ai essayé 2 sauvegardes différentes, puisque j’en ai pris 2 avant l’aventure.
Ce n’est pas bon - vous n’avez donc pas pu restaurer votre sauvegarde de l’ancienne version de Discourse avec PG12 vers une nouvelle version avec PG13 ? Pouvez-vous publier les messages d’erreur, etc. ? Tout le monde ici m’a assuré à plusieurs reprises que cela fonctionnerait.
J’aurais aimé le savoir il y a un an, mais merci !
Pour ceux qui traînent, nous avons finalement effectué une restauration complète sur une nouvelle installation sur une nouvelle VM et cela a fonctionné correctement.
).