Avez-vous quelques détails supplémentaires ? Je rencontre le même problème.
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
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.
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.
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.
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 :
J’ai essayé la mise à niveau directe mais j’ai rencontré des erreurs de classement (collation)
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
une base de données assez volumineuse (environ 80 Go)
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.
Donc, même si vous choisissez d’installer une ancienne version de Discourse, l’image forcera toujours une mise à niveau vers la version 18 ?
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.
Bonjour, j’ai un forum avec une base de données assez volumineuse (environ 80 Go). Pour la mise à niveau de la version 13 à la version 15, j’ai changé de serveur, effectué une installation fraîche et restauré les données.
Recommandez-vous toujours cette approche ? (J’ai essayé la mise à niveau directe mais j’ai rencontré des erreurs de classement)
C’est une méthode tout à fait valable si elle vous inspire plus de confiance.
l’erreur était « incompatibilité de classement » (collation mismatch)
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.
Si l’avertissement est généré lors de la préparation de la sauvegarde de l’ancienne base de données, il n’y a pas lieu de s’inquiéter.
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.
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.