Mise à jour PostgreSQL 12

:warning: ATTENTION ! Si votre base de données est très volumineuse, vous aurez besoin d’un espace disque supplémentaire important (2 fois la taille de la base de données) et devez être extrêmement prudent lors de cette mise à niveau !

Nous venons d’intégrer la mise à niveau majeure tant attendue de PostgreSQL. Tout administrateur de site reconstruisant Discourse en ligne de commande sera mis à niveau vers PostgreSQL 12 depuis l’ancienne version PostgreSQL 10.

Nous exécutons cette nouvelle version depuis un certain temps sur Meta, et tout fonctionne correctement. PostgreSQL 12 apporte de nombreuses améliorations qui seront automatiquement exploitées par Discourse.

Mise à jour

Guide d’installation officiel (conteneur unique)

Lors de votre prochaine reconstruction, vous verrez ce message à la fin :

Mise à niveau terminée
----------------

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 ! Vous devez simplement 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.

Aujourd’hui, nous avons des tâches en arrière-plan exécutant des requêtes s’étalant sur plusieurs minutes, donc arrêter le 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 sur le conteneur de données, vous pouvez suivre le journal PostgreSQL pour vérifier s’il s’est arrêté correctement.

Exécuter tail -f shared/data/log/var-log/postgres/current devrait vous donner le journal suivant si l’arrêt était propre :

2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Effectuer une mise à jour manuelle / environnements à espace limité

:warning::warning::warning:
VOUS DEVEZ FAIRE UNE COPIE DE SÉCURITÉ DES DONNÉES POSTGRES AVANT D’ESSAYER CELA
:warning::warning::warning:

Si vous êtes dans un environnement à espace limité sans aucun moyen d’obtenir plus d’espace, vous pouvez essayer ce qui suit :

./launcher stop app #(ou à la fois web_only et data si c'est votre cas)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
	-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/10/data \
	-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/12/data \
	tianon/postgres-upgrade:10-to-12
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
./launcher rebuild app #(ou d'abord data puis web_only si c'est votre cas)

Selon mes tests, cette procédure nécessite moins de 1x la taille actuelle de votre base de données en espace libre.

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.10.template.yml\".

Ceci n’est pas recommandé, car certains administrateurs de site oublieront de revenir en arrière par la suite.

Tâches optionnelles 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 :

cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit

Ou cette version en une ligne de ce qui précède :

/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"

Nettoyage des anciennes données

Pour une installation standard, vous pouvez supprimer les anciennes données au format PG10 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 ceci :

rm -fr /var/discourse/shared/data/postgres_data_old/

FAQ

Le cluster source n’a pas été arrêté proprement

Si vous obtenez un échec de mise à niveau avec le message ci-dessus, vous pouvez essayer une approche plus simple pour le remettre dans un meilleur état.

Redémarrez l’ancien conteneur avec ./launcher start app. Attendez quelques minutes jusqu’à ce qu’il soit de nouveau opérationnel.

Maintenant, arrêtez-le à nouveau avec ./launcher stop app. Après cela, suivez les journaux pour voir si c’était propre :

tail -f shared/data/log/var-log/postgres/current
2020-05-13 18:33:33.457 UTC [36] LOG:  received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG:  worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG:  shutting down
2020-05-13 18:33:33.479 UTC [36] LOG:  database system is shut down

Si les journaux ressemblent à ce qui précède, 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 paramètres régionaux non par défaut pour votre base de données. Il a été signalé 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: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

En remplaçant en_US.UTF-8 par votre paramètre régional.

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 reste encore des fichiers de la dernière mise à niveau. Déplacez-les ailleurs avant de continuer.

68 « J'aime »
Update failed (postgresql)
Trouble with latest update
Discourse Update Probs. Help please
Cant backup because of version mismatch on aws
User profile page and other features page not available
Error after Upgrading
SAML error after upgrade
Updated to latest version: ./analyze_new_cluster.sh message
Discourse 2.5.0.beta5 Release Notes
Problem with upgrading the latest version
UPGRADE OF POSTGRES FAILED - I've tried everything
Trouble with postgre(maybe)
Postgres upgrade success loop due to prior postgres 8 to 10 migration
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Failed upgrade from 2.5.0beta4 to 2.5.0beta5
Corrupt indexes in PG12, how do I fix?
PostgreSQL 13 update
Fixing discourse after disk full
LDAP Auth Missing from Plugins
Today error when upgrade from 2.5.1 to 2.5.2, discourse-assign
Discourse for Teams (Alpha Testing summer 2020)
Issue Rebuilding App Failing on Postgres Upgrade
How hard is it to handle Discourse after installation
Primary Postgres database process (postmaster) eating all CPU
Discourse failing to connect to port 3000
Upgrade of postgres failed
Search 502 errors in 2.5.0.beta6
2.6.0 beta 3 update failed on disk and/or memory space
How to backup and restore a whole /var/discourse app folder?
PostgreSQL update wrecked my forum. Please help!
Instead of auto-deleting old replies, make them auto-hide?
Add print CSS for front page and category page?
Site down after failed update: permission denied to create extension "unaccent"
Migrate quickly to separate web and data containers
Rebuild failed - FAILED TO BOOTSTRAP
Old Postgres on Docker Image with two containers: web and data
Can't rebuild due to failed postgres 12 upgrade
Should I also rebuild my data container when upgrading
Old Postgres on Docker Image with two containers: web and data
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
UPGRADE OF POSTGRES FAILED - I've tried everything
PostgreSQL 15 update
Help! Problem with firewall/permissions and postgre?
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade
Problem with upgrading the latest version
Restore failed at "EXCEPTION: x of y uploads are not migrated to S3. S3 migration failed for db 'default'."
Trouble with latest update
Can't upgrade due to old docker version
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields"
Slow Sidekiq + Postmaster using 95%+ CPU (32 cores) after Postgresql Version Upgrade