La base de données de notre instance Discourse n’est pas un conteneur local ; nous utilisons plutôt un cluster de base de données central. Récemment, le serveur PostgreSQL central a été mis à jour vers la version 18.3. J’ai constaté que la sauvegarde de Discourse échoue désormais :
[2026-05-19 03:37:37] [DÉMARRÉ]
[2026-05-19 03:37:37] « system » a lancé la sauvegarde !
[2026-05-19 03:37:37] Marquage de la sauvegarde comme en cours...
[2026-05-19 03:37:37] Vérification de l'existence de « /var/www/discourse/tmp/backups/default/2026-05-19-033737 »...
[2026-05-19 03:37:37] Vérification de l'existence de « /var/www/discourse/public/backups/default »...
[2026-05-19 03:37:37] Mise à jour des métadonnées...
[2026-05-19 03:37:37] Vidage du schéma public de la base de données...
[2026-05-19 03:37:37] pg_dump : erreur : interruption en raison d'une incompatibilité de version du serveur
[2026-05-19 03:37:37] pg_dump : détail : version du serveur : 18.3 (Ubuntu 18.3-1.pgdg24.04+1) ; version de pg_dump : 15.15 (Debian 15.15-1.pgdg12+1)
[2026-05-19 03:37:37] EXCEPTION : échec de pg_dump
[2026-05-19 03:37:37] /var/www/discourse/lib/backup_restore/creator.rb:173:in « BackupRestore::Creator#dump_public_schema »
/var/www/discourse/lib/backup_restore/creator.rb:36:in « BackupRestore::Creator#run »
/var/www/discourse/lib/backup_restore.rb:13:in « BackupRestore.backup! »
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in « Jobs::CreateBackup#execute »
Cela ressemble à un décalage de version entre le client et le serveur PostgreSQL.
La sauvegarde est exécutée depuis le conteneur Discourse, où pg_dump est en version 15.15, mais le serveur PostgreSQL externe est en version 18.3 :
server version: 18.3; pg_dump version: 15.15
Je serais prudent avant de modifier le conteneur Discourse, sauf si l’équipe Discourse le recommande. Ma première réaction serait de maintenir le cluster de base de données externe aligné sur la version de PostgreSQL que Discourse attend ou prend actuellement en charge.
OK, compris. Dans ce cas, je n’avais pas le choix, car nous avions besoin de 18 pour un autre projet utilisant le même cluster de base de données. Hmm, il semblerait que nous ayons besoin d’un serveur de base de données distinct avec 15 exclusivement pour Discourse.
Il serait peut-être possible de mettre à niveau le client sur place ?
Étant donné que vous semblez avoir prouvé la compatibilité avec PG 18 en l’utilisant comme base de données de production, cela semblerait présenter un risque faible.
J’ai effectué un test rapide avec un PostgreSQL 18 externe et une installation factice de Discourse auparavant ; aucun problème n’a été signalé. Mais, pour être honnête, ce n’était qu’un test « rapide et sale », pas un test « approfondi ». Quoi qu’il en soit, cela fonctionne depuis deux semaines, donc je suppose que tout va bien. La seule difficulté à ce jour est la sauvegarde interne à Discourse. D’un autre côté, le serveur de base de données lui-même (exécuté dans un conteneur LXC) est également sauvegardé séparément.
La politique par le passé consistait à mettre à niveau tous les deux versions. Cependant, cela fait 1 an et demi que PostgreSQL 17 a été publié et l’image Docker officielle utilise toujours la version 15, donc je ne suis pas sûr que ce soit encore le cas.
Vous pouvez ajouter du code à votre app.yml pour mettre PostgreSQL à jour vers la version correspondante. Je l’ai déjà fait, mais je ne retrouve pas mes notes. La solution la plus simple consiste à accéder au conteneur, à exécuter les commandes apt pour installer les bons clients PostgreSQL, puis à essayer la sauvegarde. Une fois que cela fonctionne, vous ajoutez ces commandes aux commandes exec de votre app.yml afin qu’elles soient exécutées automatiquement après la prochaine reconstruction.
Si vous avez besoin d’aide pour suivre les étapes, vous pouvez m’envoyer un e-mail ou poster dans Marketplace.
Cela met à jour le paquet postgres vers la version 18.
Ensuite, lancez la sauvegarde depuis l’interface d’administration, ce qui semble avoir réussi.
[2026-05-21 16:26:50] 'admin' a lancé la sauvegarde !
[2026-05-21 16:26:50] Marquage de la sauvegarde comme en cours...
[2026-05-21 16:26:50] Vérification de l'existence de '/var/www/discourse/tmp/backups/default/2026-05-21-162650'...
[2026-05-21 16:26:50] Vérification de l'existence de '/var/www/discourse/public/backups/default'...
[2026-05-21 16:26:50] Mise à jour des métadonnées...
[2026-05-21 16:26:50] Vidage du schéma public de la base de données...
[2026-05-21 16:26:50] pg_dump : exécution de SELECT pg_catalog.set_config('search_path', '', false);
[2026-05-21 16:26:50] pg_dump : dernier OID intégré est 16383
[2026-05-21 16:26:50] pg_dump : lecture des extensions
[2026-05-21 16:26:50] pg_dump : identification des membres d'extension
[2026-05-21 16:26:50] pg_dump : lecture des schémas
[2026-05-21 16:26:50] pg_dump : lecture des tables définies par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des fonctions définies par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des types définis par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des langages procéduraux
[2026-05-21 16:26:50] pg_dump : lecture des fonctions d'agrégat définies par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des opérateurs définis par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des méthodes d'accès définies par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des classes d'opérateurs définies par l'utilisateur
[2026-05-21 16:26:50] pg_dump : lecture des familles d'opérateurs définies par l'utilisateur
[... .... ...]
[2026-05-21 16:26:57] Finalisation de la sauvegarde...
[2026-05-21 16:26:57] Création de l'archive : netzwissen-forum-2026-05-21-162650-v20260520064255.tar.gz
[2026-05-21 16:26:57] Vérification que l'archive n'existe pas déjà...
[2026-05-21 16:26:57] Création d'une archive vide...
[2026-05-21 16:26:57] Archivage du vidage des données...
[2026-05-21 16:26:57] Archivage des fichiers téléchargés...
[2026-05-21 16:26:58] Suppression du répertoire temporaire '/var/www/discourse/tmp/backups/default/2026-05-21-162650'...
[2026-05-21 16:26:58] Compression gzip de l'archive, cela peut prendre un certain temps...
Super ! Je tenterais probablement d’installer spécifiquement les éléments du client pg18 afin qu’il ne bascule pas vers la version 19 à un moment donné. De plus, vous voudrez ajouter ces commandes à votre fichier app.yml, sauf si vous préférez les exécuter manuellement à chaque mise à niveau.