Bonne idée, merci Ed ! J’ai mis à jour mon message. 
2 « J'aime »
Grâce à cette modification, je constate une réduction globale de la consommation mémoire d’environ 4 %. Bravo.
2 « J'aime »
Merci Lilly, j’ai effectué la mise à niveau plus tôt et tout semble s’être bien passé 
1 « J'aime »
Il n’est pas rare que les tables et les index réécrits soient beaucoup plus compacts.
1 « J'aime »
Eh, ça fait partie du bruit de fond lié à l’exploitation de Postgres (selon qu’on regarde avant ou après un vacuum, une reconstruction de table, etc.)
Depuis, je n’ai remarqué aucun élément manquant, donc à ma connaissance, tout va bien.
1 « J'aime »
Je fais tourner Discourse dans un conteneur Docker autonome sur /var/discourse.
J’ai tenté de mettre à niveau la base de données PostgreSQL intégrée de la version 15 à la version 18. La mise à niveau semblait s’être terminée, et le répertoire de données actif signale désormais :
/shared/postgres_data/PG_VERSION
18
Cependant, le conteneur Discourse reconstruit ne contient toujours que les binaires PostgreSQL 15 :
/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18
Le service PostgreSQL est configuré pour exécuter :
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
alors que le répertoire de données Discourse réel est monté sur :
/shared/postgres_data
PostgreSQL échoue donc avec l’erreur suivante :
FATAL: database files are incompatible with server
DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).
Je comprends que les images Docker Discourse récentes sont censées inclure les binaires PostgreSQL 18. J’ai modifié app.yml pour utiliser le modèle PostgreSQL 18 et j’ai reconstruit l’application, mais le conteneur résultant contient toujours les binaires PostgreSQL 15 et le script de service pointe toujours vers /etc/postgresql/15/main.
La partie pertinente de ma configuration de service actuelle est :
HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main
Mes questions sont les suivantes :
-
Quelle est la bonne méthode pour reconstruire ou mettre à jour le conteneur Discourse afin qu’il contienne réellement les binaires PostgreSQL 18 ?
-
Y a-t-il un modèle ou une étiquette d’image spécifique à utiliser dans
app.yml? -
Une fois PostgreSQL 18 disponible, quelle est la procédure prise en charge pour le démarrer par rapport au répertoire
/shared/postgres_dataexistant ?
Je n’ai pas supprimé ni réinitialisé le répertoire de données PostgreSQL 18. Je préfère récupérer le cluster mis à niveau plutôt que de restaurer les anciennes données PostgreSQL 15.
1 « J'aime »
D’après les instructions de l’OP, cela semble être une étape inutile, sauf si je me trompe ?
Il aurait suffi de reconstruire une installation standard pour télécharger l’image la plus récente et déclencher la migration.
À moins de choisir expressément de ne pas utiliser l’image la plus récente, les nouveaux binaires étaient-ils vraiment garantis ? Très étrange…
Es-tu sûr de ne pas avoir verrouillé une version d’image ?
3 « J'aime »
Pas volontairement ? Je suis sur le dépôt git et la branche habituels, et rien dans mon app.yml ne m’indique que j’ai épinglé quoi que ce soit. Je suis simplement passé au modèle postgres 18 pour voir si cela aiderait ; oui, c’était une étape inutile qui n’a pas aidé, donc je peux revenir en arrière.
Avez-vous des suggestions sur la façon d’obtenir les nouveaux binaires ? Ils ne sont vraiment pas là, malgré le nombre de fois où je reconstruis :
root@hostname-app:/usr/lib/postgresql# ls -la
total 12
drwxr-xr-x 1 root root 4096 May 21 00:47 .
drwxr-xr-x 1 root root 4096 May 21 00:48 ..
drwxr-xr-x 1 root root 4096 May 21 00:47 15
root@hostname-app:/usr/lib/postgresql#
1 « J'aime »
Pour vous faire gagner du temps et éviter les ennuis, je vous suggère d’utiliser votre dernière sauvegarde pour créer un nouveau serveur ; cela vous évitera beaucoup de travail.
1 « J'aime »
D’accord, je suppose que oui ! Parfois, ça ne vaut pas le coup de s’embêter à réparer les choses. Merci.
2 « J'aime »
Lorsque vous ne pouvez pas accéder au panneau d’administration parce que votre instance Discourse a décidé de perdre la tête, comment récupérez-vous la base de données via root@ afin de la téléverser sur une nouvelle instance ? (peut-être un autre guide)
Ou quelle est la commande à exécuter en ligne de commande pour effectuer la même opération que celle réalisée via le panneau d’administration ?
Ok, et pour en venir au cœur du sujet, il faut reconstruire l’application pour corriger une erreur de certificat qui semble s’être produite sans raison apparente (aucune modification n’a précédé l’échec) — l’erreur « port 443 inaccessible » apparaît (l’assistant indique : « Échec de la vérification DNS ») — je ne sais pas si Cloudflare ou DigitalOcean a changé quelque chose, mais encore une fois, rien n’a été modifié de mon côté — eh bien, je ne peux pas reconstruire en raison de ces deux erreurs, y compris celle ci-dessous, contrairement à la dernière fois où il s’agissait d’une erreur de manque d’espace. Avez-vous une idée pour contourner celle-ci ?
À noter, j’ai également rencontré exactement la même erreur avant et après avoir augmenté la taille du disque principal (pour répondre aux besoins de la migration de PostgreSQL 15 à 18).
FAILED
--------------------
Pups::ExecError: if [ -f /root/install_postgres ]; then
/root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi
failed with return #<Process::Status: pid 17 exit 1>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}
Ah, d’accord, j’ai trouvé ce que je crois être ce dont j’ai besoin, publié par @Lilly il y a longtemps dans ce sujet.
cd /var/discourse
./launcher enter web_only
discourse backup
exit
J’en déduis que je peux ainsi générer une sauvegarde de base de données utilisable, que je pourrai téléverser sur une nouvelle instance Discourse pour contourner tous les problèmes.
Cette commande génère-t-elle une sauvegarde complète, c’est-à-dire les messages + les téléversements/images ?
Je recommande une sauvegarde uniquement de la base de données et l’utilisation de rsync pour transférer tout le reste. Transférer un site Discourse vers un autre VPS avec rsync. Vous pouvez également utiliser rsync pour transférer les certificats SSL afin de mettre en ligne le nouveau site avant de modifier le DNS.
Voici comment je procède : Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard
MODIF : Désolé. Je ne sais pas si vous avez résolu votre problème. Si j’ai bien compris, la chose la plus simple à faire est de revenir au modèle par défaut, sans version, et de reconstruire.
2 « J'aime »
As-tu reconstruit le conteneur de données (probablement « app » dans ton cas) deux fois, comme demandé ?
(Au fait, le message de mise à jour indique de reconstruire « app », mais je suppose qu’il s’agissait de « le conteneur de base de données, qui peut s’appeler app ou data » ou bien les deux ?)
Et un petit retour : il y a quelque temps, j’ai essayé de passer de la version 13 à la 15, mais ça a échoué à plusieurs reprises et je suis resté sur le modèle .13. Maintenant que la version .18 est proposée, j’ai réessayé et ça a fonctionné sans aucun problème (il m’a juste fallu nettoyer les dossiers _new et _older avant). Je peux donc à nouveau utiliser le modèle de données par défaut non versionné. Bravo pour avoir rendu la mise à jour si robuste !
1 « J'aime »
Je viens de remarquer dans le journal d’erreurs qu’avant la mise à jour de PG, il y avait apparemment des erreurs liées au SQL dans les journaux :
Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...
C’est étrange, car cette fonction semble provenir de PG9, alors que j’utilisais la version 15 avant. Pourrait-il s’agir d’un problème de permissions ou de chemin de recherche (search path) ? Il semble que cela ne se produise plus après la mise à jour de la base de données, mais peut-être est-ce une question de synchronisation des lots (batch timing)… Je vois que cette fonction est utilisée dans de nombreux endroits, y compris dans des scripts de migration.
Peut-être cela signifie-t-il que certaines fonctions échouent sur les anciennes versions de PostgreSQL, même si leurs modèles sont toujours répertoriés. J’ai peut-être manqué quelque chose, mais je pensais que les anciennes versions étaient compatibles.
1 « J'aime »