Juste pour info—n’essayez pas cette mise à jour pendant les heures de pointe.
La mise à jour 2.6.0b2 tourne sur notre serveur depuis plus de 40 minutes, alors qu’elle prend normalement seulement quelques minutes, souvent terminée avant même que vous ne reveniez vérifier. J’étais inquiet qu’elle soit bloquée, mais en me connectant à PostgreSQL, je vois une grosse mise à jour en cours, qui semble modifier les données de recherche des posts pour les messages privés.
J’espère qu’elle n’est pas bloquée. Je vais bien voir. Je ne veux vraiment pas l’arrêter ou redémarrer le conteneur en plein milieu de la mise à jour.
Requête en cours :
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
La mise à niveau a été assez lente pour moi, même sur du matériel colocalisé rapide. Je ne suis pas tout à fait sûr de la raison, mais c’est certainement quelque chose à garder à l’esprit.
Ouais, je suggère d’ajouter une note dans le journal des modifications pour avertir les utilisateurs que cette mise à jour prendra probablement beaucoup plus de temps que la plupart des autres, et de ne pas l’arrêter ni faire quoi que ce soit de radical, car c’est normal.
@Wingtip Puis-je vérifier le nombre de messages que vous avez sur votre forum ? Malheureusement, cela risque d’être lent sur les sites comportant un grand nombre de messages.
Mon site local n’avait pas tant de publications que ça et il était tout de même assez lent. Pas lent de 40 minutes, mais nettement plus lent que les mises à niveau précédentes, peut-être de 3 à 4 fois ?
Merci @Wingtip, je pensais que cela ne nous arrivait qu’à nous !
En fait, j’ai dû annuler la reconstruction et redémarrer l’application car je pensais qu’elle était bloquée sur la requête que vous mentionnez. Nous avons 6 millions de publications et après environ 45 minutes, elle n’était toujours pas terminée. Je suppose donc que je devrai prévoir au moins une heure pour la reconstruction et prévenir nos utilisateurs à l’avance.
Je viens de sortir un chronomètre et de tester une reconstruction (site avec environ 1 million de publications uniquement) de la version 2.6.0b1 vers b2 ; du début à la fin, cela a pris 170 secondes.
C’est ma deuxième reconstruction aujourd’hui, passant de b1 à b2, et tout semble très bien se passer, sans différence notable dans la vitesse de construction.
Remarque : Nous effectuons toujours les mises à jour en ligne de commande et n’utilisons pas l’interface utilisateur.
Je n’utilise pas non plus le gestionnaire Docker et préfère reconstruire en ligne de commande. C’est mieux ainsi pour voir les journaux en cas de problème. Je pense aussi que c’est plus rapide.
J’ai (imprudemment) procédé à la mise à niveau via la console web, je n’ai donc pas eu accès à un journal à jour en continu. Je ne referai plus cette erreur.
J’avais un grand site qui échouait systématiquement au démarrage. Il s’agissait d’une installation à deux conteneurs, de sorte que l’ancien conteneur continuait de fonctionner pendant que le démarrage exécutait la migration. J’ai finalement résolu le problème en activant SKIP_POST_DEPLOYMENT_MIGRATIONS=1 pour le démarrage, puis en lançant les migrations une fois le nouveau conteneur démarré. Avec SKIP_POST_DEPLOYMENT_MIGRATIONS=1 dans la section ENV, la migration était très rapide ; le site a ensuite pu fonctionner normalement (bien que peut-être plus lentement) pendant l’exécution des migrations, ce qui a pris, je crois, plus de 20 minutes.
Je pense, mais je ne l’ai pas encore testé, que cette même astuce permettrait de minimiser les temps d’arrêt lors d’une installation en un seul conteneur. Si j’ai raison, voici ce qu’il faudrait faire :
ajouter SKIP_POST_DEPLOYMENT_MIGRATIONS=1 dans votre app.yml
./launcher rebuild app
./launcher enter app
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
annuler la modification dans app.yml, sauf si vous prévoyez de vous souvenir d’exécuter les migrations après chaque mise à niveau
éventuellement reconstruire à nouveau pour vous assurer qu’aucun problème ne survient pendant que vous vous souvenez encore de ce qui a pu casser votre site ; dans quatre mois, lorsque vous réessayerez, vous n’aurez plus aucune idée de la cause, et il sera difficile pour quiconque de deviner quel est le problème.
S’il existait un moyen que ./launcher transmette SKIP_POST_DEPLOYMENT_MIGRATIONS=1 sans nécessiter une modification de app.yml, cela rendrait les choses moins fastidieuses pour ceux qui ont des difficultés avec l’édition.
Si je parviens à effectuer le travail que je prévois sur ce sujet, je créerai un nouveau sujet pour rapporter mes découvertes. Cependant, la fumée m’a confiné dans une pièce où je n’ai pas mon grand moniteur. (La pandémie ne suffisait-elle pas ? Devons-nous aussi subir la fumée ? Et je ne suis même pas particulièrement proche de ce maudit incendie.)
C’est une excellente nouvelle ! (Deux autres projets ont pris le dessus aujourd’hui et, d’une manière ou d’une autre, mon instance multisite ne fonctionne plus correctement avec S3. ) Merci beaucoup.
Y a-t-il une raison technique pour laquelle les modifications de base de données post-mise à niveau doivent être bloquantes par défaut ? Existe-t-il un moyen de modifier ce comportement afin que les futures mises à niveau remettent le site en ligne rapidement, puis exécutent les opérations post-mise à niveau en arrière-plan ?
À mon avis, tout ce qui est essentiel au bon fonctionnement de l’application mise à niveau, comme les opérations DDL, devrait faire partie intégrante de la mise à niveau elle-même, et non des scripts post-mise à niveau.
Édition : en attendant, j’ai tué le processus pour que le site redevienne accessible à nos utilisateurs. Mais il doit y avoir une meilleure façon de procéder à cette mise à jour.
) Merci beaucoup.