Donc, quelque part, vous avez changé le port postgres en 50432 au lieu de 5432 ? (OU peut-être que le code de migration le fait et je ne l’ai jamais remarqué).
Peut-être passer au modèle postgres13 comme suggéré dans le message d’origine ? Et si cela fonctionne, ce que je ferais, c’est passer à un nouveau serveur et éviter tout le problème de transition vers une nouvelle version de postgres, et simplement restaurer la base de données sur le nouveau serveur.
Je n’ai pas assez d’espace pour effectuer cette mise à niveau sur ma partition Discourse. Cependant, j’ai beaucoup d’espace sur un autre disque. Y a-t-il un moyen de l’utiliser pour le stockage temporaire ?
Il est probablement temps de mettre à niveau le système d’exploitation de toute façon, et le passage à une nouvelle VM est beaucoup plus facile, nécessite peu de temps d’arrêt, et si quelque chose tourne mal, vous avez toujours un serveur fonctionnel.
Si vous avez un conteneur de données séparé, vous pouvez essayer de déplacer tout /var/discourse/shared/data vers l’autre partition et d’ajuster les volumes dans votre YML en conséquence.
Et si vous n’avez pas de conteneur séparé, vous pouvez faire quelque chose comme ça, c’est juste plus compliqué.
J’ai un problème similaire (identique ?) . Avez-vous vérifié le journal mentionné ?
Dans mon cas : Lors de la mise à jour, j’ai d’abord eu un problème avec le conteneur de l’application (dans mon cas, uniquement web) qui ne reconstruisait pas car j’avais ajouté le “rss-polling” en tant que plugin personnalisé, et cela semble entrer en conflit avec les nouveaux paramètres par défaut. Après l’avoir supprimé, cela a fonctionné.
Mais ensuite, il y a eu des problèmes avec l’extension vectorielle manquante. C’est parce que je n’avais pas reconstruit le conteneur de données depuis un certain temps. J’ai réussi à le faire jusqu’à la version 13, mais maintenant je suis bloqué avec la version 13 en cours d’exécution. Lorsque je modifie mon fichier data.yaml pour utiliser postgres.template ou postgres.15.template, la migration échoue.
Elle a d’abord échoué avec “unclean shutdown” et avec les indices ci-dessus, j’ai pu résoudre ce problème. Mais maintenant, la migration échoue, car il semble manquer l’installation de la version 13 ? Est-ce peut-être lié à des restes dans le répertoire /shared ? (J’ai déjà essayé de nettoyer le répertoire postgres_new).
-----------------------------------------------------------------
pg_upgrade run on Fri Oct 17 09:54:37 2025
-----------------------------------------------------------------
command: "/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" -D "/shared/postgres_data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" 2>&1
waiting for server to start....2025-10-17 09:54:37.744 UTC [1900] LOG: starting PostgreSQL 13.22 (Debian 13.22-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-10-17 09:54:37.749 UTC [1900] LOG: listening on Unix socket "/var/lib/postgresql/.s.PGSQL.50432"
2025-10-17 09:54:37.760 UTC [1900] LOG: could not open configuration file "/etc/postgresql/13/main/pg_hba.conf": No such file or directory
2025-10-17 09:54:37.760 UTC [1900] FATAL: could not load pg_hba.conf
2025-10-17 09:54:37.762 UTC [1900] LOG: database system is shut down
stopped waiting
pg_ctl: could not start server
Examine the log output.
Ce que je ferais probablement, c’est revenir à PG13 avec l’ancien conteneur (si vous parvenez à le faire fonctionner), puis faire une sauvegarde et passer à un nouveau serveur (vous aurez probablement besoin d’un nouveau système d’exploitation de toute façon).
Il semble que le conteneur que vous avez est dans un état dégradé. Essaie-t-il de reconstruire avec le modèle PG13 ? Vous devrez peut-être déplacer le dossier de sauvegarde postgres vers postgres_data et revenir à la version 13 pour que les choses repartent.
Oui, j’utilise actuellement le conteneur PG13. Je l’ai reconstruit plusieurs fois. J’ai même nettoyé le répertoire _new en suspens. C’est juste que chaque fois que j’essaie d’aller à 15 ou au modèle officiel non versionné, cela échoue. Je vais le migrer manuellement bientôt si cela ne se résout pas. Je ne vois pas en quoi le système d’exploitation est pertinent ici.
Je restructurerais votre montage de volume de sorte que l’intégralité du répertoire Shared ou shared/postgres se trouve sur le même volume, ainsi les renommages de répertoire (qui sont régulièrement nécessaires) ne poseront plus de problème.
Il se peut qu’il ne soit pas lié au problème immédiat. Il est fréquent que si vous utilisez Discourse depuis assez longtemps pour avoir besoin d’une mise à niveau de PostgreSQL, vous ayez également besoin d’une mise à niveau du système d’exploitation.
Passer à un nouveau serveur vous permet de le faire avec pratiquement aucun temps d’arrêt et aucun risque de vous retrouver dans un état instable.
D’un autre côté, la plupart des mises à niveau que j’ai effectuées avec mon script (qui fait simplement ce qui est décrit ici) se sont déroulées sans problème.
Je pense que vous passeriez à celui qui n’est pas versionné, puis vous feriez les deux reconstructions.
