Cette mise à niveau recommandée a échoué et n’a pas permis de rétablir mon forum après l’avoir interrompu. J’exécute maintenant discourse-doctor pour essayer de le réparer, et si cela échoue également, j’ai pris un instantané de la VM.
Sortie :
2023-04-19 18:28:31.298 UTC [42] LOG: reception d'une demande d'arrêt rapide
2023-04-19 18:28:33.651 UTC [65] LOG: arrêt en cours
2023-04-19 18:28:33.974 UTC [42] LOG: le système de base de données est arrêté
ÉCHEC
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' a échoué avec le retour #<Process::Status: pid 59 exit 2>
Emplacement de l'échec : /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
l'exécution a échoué avec les paramètres « su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"' »
l'amorçage a échoué avec le code de sortie 2
** ÉCHEC DE L'AMORÇAGE ** veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
La commande s'est terminée avec un statut non nul 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
Vous pouvez essayer de redémarrer votre conteneur avec
./launcher start app
mais c’est ce que discourse-doctor devrait faire.
Vous devrez fournir plus de sortie car l’erreur se situe au-dessus de ce que vous avez inclus.
J’ai essentiellement demandé cela, en mettant à niveau une heure après cette notification et en étant le premier à le faire. Pas de véritable stress avec ce snapshot auparavant, alors j’ai pris un coup pour l’équipe ici, les gars.
2023-04-19 18:28:26.755 UTC [45] LOG: la base de données n’a pas été arrêtée correctement ; récupération automatique en cours
Si votre base de données ne peut pas s’arrêter en toute sécurité en 60 secondes, ce qui arrivera avec de grandes bases de données sur des disques plus lents, elle entrera dans cet état et échouera lors d’une reconstruction si elle ne peut pas récupérer en 5 secondes (ce qui est rare car elle est grande/lente).
Cela n’a rien à voir avec les changements listés ici, et c’est un problème dans Discourse depuis au moins 2016.
Ahh, merci. Peut-être qu’il faudrait attendre plus longtemps pour les forums plus grands comme le nôtre. Si vous arrêtez simplement le processus de la base de données, elle devra annuler les transactions après son redémarrage, ce qui peut prendre très longtemps.
La terminologie concernant la bêta est quelque peu confuse. Le tableau de bord d’administration indique que nous utilisons la bêta, y a-t-il un autre endroit où nous aurions dû regarder ? Ma compréhension est que la bêta est recommandée pour Discourse, sur la base des annonces de sortie qui déconseillent l’utilisation de la branche stable.
Quand les années 60 ont-elles été décidées pour un arrêt en toute sécurité ? Combien d’installations sont maintenant beaucoup plus importantes qu’à l’époque ?
Idéalement, cette attente de 60 secondes devrait être davantage une attente en boucle fermée, avec une limite. Il semble que la limite devrait être plus élevée, s’il existe maintenant de nombreuses instances qui sont maintenant vulnérables.
Je pense avoir vu que c’était au moins depuis 2016. Mais les choses ont changé. EDIT : Voici un nouveau commit.
Je ne pense pas que beaucoup d’installations standard soient dans ce cas, car c’est ainsi depuis presque le début.
Ouais. C’est une grosse base de données. Je soupçonne que peu de gens ont une base de données aussi volumineuse qui ne soit pas sur RDS ou du moins dans un conteneur séparé. Vous devriez probablement envisager de passer à une installation à 2 conteneurs.
Nous allons y réfléchir, la méthode de commutation est-elle documentée ? Et y a-t-il d’autres avantages qu’une augmentation du minuteur de 60 secondes ne fournirait pas ?
Vous pouvez construire un nouveau conteneur pendant que l’ancien continue de fonctionner. Vous n’avez pas besoin d’arrêter la base de données pour construire un nouveau conteneur.
Il y a maintenant une fenêtre de 10 minutes pour l’arrêt de postgres, ce qui devrait résoudre votre problème actuel. Une fois que vous aurez fait une autre reconstruction, vous aurez 10 minutes au lieu d’une.
Ce type vient de créer une nouvelle instance de deux conteneurs, puis a restauré à partir de la sauvegarde. Nous ne ferons certainement pas cela sans une bonne raison, j’ai juste dû le faire pour éviter les exigences d’espace disque de la mise à niveau PG13 il y a environ 2 mois.
Nous y sommes maintenant, celle-là était finalement inévitable ! Au-delà de la base de données, nous devions également passer de la version 18.04LTS, qui n’est plus prise en charge.
S’il existe une documentation sur la façon de le faire sans une reconstruction complète à partir de zéro, alors la restauration des sauvegardes sera certainement prise en considération.