Avez-vous quelques détails supplémentaires ? Je rencontre le même problème.
1 « J'aime »
Pour ceux qui rencontrent le même problème, voici le résumé (IA) de ce que j’ai fait :
Démarrer temporairement PG15 → Exporter la base de données → Utiliser PG18 → Restaurer l’export
1 « J'aime »
Donc, oui, cette mise à niveau est basée sur des images.
Donc, même si vous choisissez d’installer une ancienne version de Discourse, l’image forcera-t-elle toujours la mise à niveau vers la version 18 ?
C’est clair.
1 « J'aime »
Je vois que tu l’as corrigé, mais la méthode proposée par ChatGPT, bien qu’elle ait résolu l’erreur, a quand même effacé ma base de données : plus aucun compte, aucun sujet ni aucun message.
Heureusement, il s’agissait d’un forum de développement relativement récent, donc les pertes n’ont pas été trop importantes.
2 « J'aime »
On a pris beaucoup de précautions pour que cela ne se produise pas aujourd’hui. À chaque étape, on me confirmait que rien ne serait supprimé, et j’avais l’impression que nous avions vérifié à trois reprises que toutes les données avaient été migrées avant de convenir de supprimer ce qui n’était plus nécessaire.
Mais si les choses avaient mal tourné, les seules données que j’aurais perdues auraient été la configuration du composant de thème.
1 « J'aime »
Salut, j’ai un forum avec une base de données assez volumineuse (environ 80 Go). Pour passer de la version 13 à la 15, j’ai changé de serveur, effectué une nouvelle installation et restauré les données.
Recommandez-vous cette même démarche ? (j’ai essayé la mise à jour directe, mais j’obtiens des erreurs de collation)
Plus tôt dans le sujet, l’équipe a déclaré :
Donc, oui, c’est une option.
Vous avez déjà dit :
Erreurs de classement ? Quelle est la version du Discourse existant ?
Peut-être poster les erreurs que vous avez rencontrées / la sortie de la console
mais vous n’avez pas manqué d’espace (2 x la taille de la base de données existante est recommandée) ?
Salut, j’ai de l’espace (250 Go libres), l’erreur était « collation mismatch », mais il me semble que je n’ai pas les chaînes utf dans le fichier app.yml.
1 « J'aime »
Nous essayons de fournir des valeurs par défaut sensées dans les images discourse_docker, mais il est impossible de prendre en compte chaque cas d’utilisation possible. N’hésitez pas à personnaliser vos images pour conserver des versions antérieures si vous le préférez.
Dans une certaine mesure, les versions des dépendances reflètent nos exigences d’hébergement — nous utilisons l’image de base en interne. Cela signifie qu’elle ne doit pas devenir trop obsolète, mais cela implique aussi qu’il n’y a qu’un nombre limité de permutations que nous pouvons maintenir.
C’est une méthode tout à fait valable si elle vous inspire plus de confiance.
Si l’avertissement est généré lors de la préparation de l’exportation de l’ancienne base de données, il n’y a aucune raison de s’inquiéter. Nous exécutons le serveur uniquement contre l’ancien répertoire de données dans le but d’exécuter pg_dump. Lorsque l’exportation est restaurée sur le nouveau serveur, les index sont recréés.
La raison pour laquelle vous voyez cela est que nous avons publié ces derniers jours une nouvelle version de l’image de base qui passe de Debian Bookworm à Trixie, modifiant ainsi la version de glibc. Les locales basées sur le fournisseur libc (que vous utilisiez probablement) ne sont pas stables lors des mises à niveau de glibc, donc lorsque le script de mise à niveau démarre un serveur Postgres pour exporter vos anciennes données, il affiche des avertissements d’incompatibilité de classement.
Cette incompatibilité de classement est la raison principale pour laquelle nous effectuons une exportation et une restauration au lieu d’exécuter pg_upgrade. Une fois que votre base de données utilise C.UTF-8 avec le fournisseur builtin, les mises à niveau de glibc n’affecteront plus les classements.
2 « J'aime »
J’ai effectué la mise à niveau ce soir et tout s’est déroulé comme prévu. J’ai obtenu les mêmes avertissements concernant le classement de la base de données, mais il semble que nous devions les ignorer. Merci.
2 « J'aime »
J’ai essayé d’ajouter dans app.yml
app.yml
templates:
- “templates/postgres.15.template.yml”
- “templates/redis.template.yml”
- “templates/web.template.yml”
- “templates/web.ratelimited.template.yml”
Pour reporter la mise à niveau, mais j’obtiens cette erreur
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Lieu de l’échec : /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d’erreur précédents, il peut y en avoir plus d’un.
./discourse-doctor peut aider à diagnostiquer le problème.
Ça a l’air d’être le mauvais conteneur de base, je crois. As-tu exécuté ./launcher rebuild ? Cela devrait déclencher un git pull, mais tu pourrais essayer d’exécuter un git pull pour voir si cela change quelque chose.
1 « J'aime »
Même erreur
Digest : sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Statut : Image plus récente téléchargée pour discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
Vérification que le launcher est à jour
Le launcher est à jour
Arrêt de l’ancien conteneur
- /usr/bin/docker stop -t 600 app
app
2.0.20260812-0036 : Tirage depuis discourse/base
Digest : sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Statut : L’image est à jour pour discourse/base:2.0.20260812-0036
docker.io/discourse/base:2.0.20260812-0036
/usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2026-08-25T06:22:16.249062 #1] INFO – : Lecture depuis stdin
I, [2026-08-25T06:22:16.274434 #1] INFO – : Fichier > /etc/service/postgres/run chmod: +x chown:
I, [2026-08-25T06:22:16.281650 #1] INFO – : Fichier > /etc/service/postgres/log/run chmod: +x chown:
I, [2026-08-25T06:22:16.287846 #1] INFO – : Fichier > /etc/runit/3.d/99-postgres chmod: +x chown:
I, [2026-08-25T06:22:16.293208 #1] INFO – : Fichier > /root/install_postgres chmod: +x chown:
I, [2026-08-25T06:22:16.299851 #1] INFO – : Fichier > /root/upgrade_postgres chmod: +x chown:
ÉCHEC
Errno::ENOENT : Aucun fichier ou dossier de ce type @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Lieu de l’échec : /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
L’échec de la substitution avec les paramètres {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
Échec du bootstrap avec le code de sortie 1
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d’erreur antérieurs, il peut y en avoir plus d’un.
./discourse-doctor peut aider à diagnostiquer le problème.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1
1 « J'aime »
Je pense avoir trouvé la cause.
L’image de base actuelle installe le serveur PostgreSQL 18, mais postgres.15.template.yml suppose toujours que les paquets du serveur PostgreSQL 15 sont déjà présents. Il accède donc à :
/etc/postgresql/15/main/postgresql.conf
avant que ce fichier n’existe, ce qui provoque l’erreur ENOENT mentionnée ci-dessus.
J’ai ouvert une petite PR qui fait en sorte que le modèle de maintien de PostgreSQL 15 supprime les paquets du serveur PostgreSQL 18 et installe les paquets du serveur PostgreSQL 15 avant de configurer PostgreSQL :
Cela devrait rétablir le chemin prévu, où le changement de postgres.template.yml en postgres.15.template.yml retarde la mise à niveau de PostgreSQL 18.
4 « J'aime »
La mise à jour a-t-elle été publiée ?
Pourrai-je réessayer quand ? (juste pour information)
J’ai fusionné le correctif (merci @Ethsim2 !), tu peux donc réessayer.
2 « J'aime »
Ça fonctionne, merci beaucoup !
2 « J'aime »
L’upgrade s’est bien passé pour ceux qui ont plusieurs conteneurs sur le même serveur ? Si j’ai le temps ce week-end, je pourrais mettre à niveau le nôtre — je voulais juste vérifier ici avant, au cas où il vaudrait mieux que j’attende un peu…
oui, j’ai effectué des mises à niveau sur des conteneurs doubles sur un seul serveur il y a quelques semaines (sur un serveur russe aussi). Aucun problème du tout, mais assurez-vous d’abord d’avoir suffisamment d’espace disque.
3 « J'aime »
Astuce pour ceux qui effectuent des mises à jour de PostgreSQL en dehors de Docker. Vous pouvez utiliser --link avec pg_upgrade pour éviter de copier les données. Il est possible de créer des liens durs sur ces données, ce qui permet d’économiser de l’espace disque.
2 « J'aime »