ATTENTION ! La mise à jour nécessite beaucoup d’espace disque libre (2x la taille de la base de données).
Nous venons de déployer des modifications pour mettre à niveau notre image Docker vers PostgreSQL 18. Tous les administrateurs de site qui reconstruisent Discourse depuis la ligne de commande seront mis à niveau de PostgreSQL 15 vers PostgreSQL 18. Notez que si vous aviez reporté la mise à jour lorsque PostgreSQL 15 est sorti en 2025, vous pouvez passer cette étape et passer directement à PostgreSQL 18.
Si vous aviez reporté la mise à niveau précédemment, changez le modèle PostgreSQL dans app.yml de templates/postgres.13.template.yml à templates/postgres.template.yml.
Comme pour toute mise à niveau, il est fortement recommandé de faire une sauvegarde avant toute action.
Changements de locale
Auparavant, nous avions constaté des corruptions d’index lors de la mise à jour de glibc, par exemple lors des mises à niveau du système d’exploitation. Depuis PostgreSQL 17, il existe un nouveau fournisseur de locale intégré qui est découplé de la glibc du système d’exploitation et donc stable entre les versions. Dans le cadre de cette mise à niveau, nous passons à ce fournisseur intégré en utilisant la locale C.UTF-8. Cette locale utilise l’ordre des points de code et nous la recommandons pour les raisons de stabilité mentionnées ci-dessus.
Afin d’effectuer ce changement de locale, nous devons d’abord créer le nouveau cluster de base de données en utilisant le fournisseur de locale intégré, puis nous exportons et restaurons la base de données dans ce cluster. Pour cette raison, les exigences en matière d’espace disque sont plus élevées que lors des mises à niveau précédentes où nous effectuions des mises à niveau sur place.
Mise à jour
Guide d’installation officiel (conteneur unique)
Lors de votre prochaine reconstruction, vous verrez ce message à la fin :
-------------------------------------------------------------------------------------
MISE À NIVEAU DE POSTGRES TERMINÉE
L'ancienne base de données 15 est stockée dans /shared/postgres_data_old
Pour terminer la mise à niveau, reconstruisez à nouveau en utilisant :
./launcher rebuild app
-------------------------------------------------------------------------------------
Cela signifie que tout s’est bien passé lors de la mise à niveau ! Il vous suffit de lancer une nouvelle reconstruction pour remettre votre site en ligne.
Installation avec conteneur de données
Si vous utilisez une configuration avec un conteneur de données dédié basé sur l’exemple fourni dans notre dépôt discourse_docker, assurez-vous d’arrêter PostgreSQL de manière sûre et propre.
De nos jours, nous avons des tâches en arrière-plan qui exécutent des requêtes s’étalant sur plusieurs minutes, donc l’arrêt du conteneur web aidera à arrêter le conteneur de données en toute sécurité.
./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only
Avant de lancer la première reconstruction du conteneur de données, vous pouvez suivre le journal PostgreSQL pour voir s’il a été arrêté correctement.
Exécuter tail -f shared/standalone/log/var-log/postgres/current devrait vous donner le journal suivant si l’arrêt a été propre :
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Reporter la mise à jour
Si vous devez reporter la mise à jour lors de votre prochaine reconstruction, vous pouvez remplacer le modèle PostgreSQL dans votre fichier app.yml en changeant "templates/postgres.template.yml" par "templates/postgres.15.template.yml".
Ceci n’est pas recommandé, car certains administrateurs de site oublieront de revenir en arrière par la suite.
Tâches facultatives après la mise à jour
Optimisation des statistiques PostgreSQL
Après la mise à jour, le nouveau PostgreSQL n’aura pas les statistiques de table à portée de main. Vous pouvez les générer en utilisant :
docker exec -u postgres app \
/usr/lib/postgresql/18/bin/vacuumdb -d discourse --analyze-in-stages
Nettoyage des anciennes données
Pour une installation standard, vous pouvez supprimer les anciennes données au format PG15 avec la commande suivante :
cd /var/discourse
./launcher cleanup
Si vous avez un conteneur de données séparé, vous devrez supprimer la copie de sauvegarde comme suit :
rm -fr /var/discourse/shared/data/postgres_data_old/
FAQ
Le cluster source n’a pas été arrêté proprement
Si vous obtenez une erreur de mise à niveau avec le message ci-dessus, vous pouvez essayer une approche plus simple pour le remettre dans un état meilleur.
Redémarrez l’ancien conteneur avec ./launcher start app. Attendez quelques minutes jusqu’à ce qu’il soit de nouveau en ligne.
Maintenant, arrêtez-le à nouveau avec ./launcher stop app. Après cela, suivez les journaux pour voir si l’arrêt a été propre :
tail -f shared/standalone/log/var-log/postgres/current
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Si les journaux n’indiquent pas que la base de données est arrêtée, vous pouvez redémarrer l’ancien conteneur, entrer avec ./launcher enter app, exécuter ces commandes et suivre à nouveau les journaux une fois terminé.
export SVWAIT=300
sv stop nginx
sv stop unicorn
sv stop postgres
exit
Si les journaux ressemblent à ceux ci-dessus, vous pouvez maintenant essayer de mettre à niveau à nouveau en utilisant ./launcher rebuild app.
Les valeurs lc_collate pour la base de données “postgres” ne correspondent pas
Cette erreur se produit si vous utilisez des locales non par défaut pour votre base de données. Il a été rapporté que vous avez besoin de 3 variables pour que cela réussisse. Assurez-vous que la section env: de votre fichier app.yml contient les 3 lignes :
LC_ALL: fr_FR.UTF-8
LANG: fr_FR.UTF-8
LANGUAGE: fr_FR.UTF-8
En remplaçant fr_FR.UTF-8 par votre locale.
Chaque reconstruction effectue à nouveau la mise à niveau, c’est-à-dire une boucle de mise à niveau
Lorsque cela se produit, vos journaux de mise à niveau contiendront
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old/postgres_data': Directory not empty
mv: cannot move '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new': Directory not empty
Cela signifie qu’il y a encore des fichiers de la dernière mise à niveau qui traînent. Déplacez-les ailleurs avant de continuer.
J’ai sauté la mise à jour PostgreSQL 15, que faire maintenant ?
Vous pouvez suivre les instructions standard en haut de ce guide et elles mettront à niveau votre version vers 18 sans problème.
