Lors de la mise à niveau, j’ai rencontré
Arrêt du serveur de base de données PostgreSQL 15 : mainErreur : le propriétaire de la configuration (postgres:101) et le propriétaire des données (runit-log:999) ne correspondent pas, et le propriétaire de la configuration n’est pas root … échec !
échec !
impossible d’ouvrir le fichier de version « /shared/postgres_data/PG_VERSION » : Permission refusée
Échec, sortie
Ce qui a été résolu par
sudo ./launcher enter app
puis
chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
Je suis dans une boucle infinie, la base de données a été mise à jour correctement mais lorsque j’exécute ./launcher rebuild app, cela boucle indéfiniment. La seule chose que je puisse voir est ce qui suit :
EDIT : J’ai trouvé ce message…
mv : impossible de déplacer '/shared/postgres_data_new' vers '/shared/postgres_data/postgres_data_new' : impossible de supprimer la cible : Le répertoire n'est pas vide
Votre installation contient des extensions qui devraient être mises à jour
avec la commande ALTER EXTENSION. Le fichier
update_extensions.sql
lorsqu'il est exécuté par psql par le superutilisateur de la base de données mettra à jour
ces extensions.
S’il vous plaît, conseillez-moi.
Mise à niveau terminée
----------------
Les statistiques de l'optimiseur ne sont pas transférées par pg_upgrade.
Une fois que vous démarrez le nouveau serveur, envisagez d'exécuter :
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
L'exécution de ce script supprimera les fichiers de données de l'ancien cluster :
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
MISE À NIVEAU DE POSTGRES TERMINÉE
L'ancienne base de données 13 est stockée à /shared/postgres_data_old
Pour terminer la mise à niveau, reconstruisez à nouveau en utilisant :
./launcher rebuild app
-------------------------------------------------------------------------------------
Ok, il semble que ce soit le problème ici :
Ceux-ci sont situés dans shared/standalone/ et ont déjà été déplacés manuellement…
mv : impossible de déplacer '/shared/postgres_data' vers '/shared/postgres_data_old' : Périphérique ou ressource occupé
mv : impossible de déplacer '/shared/postgres_data_new' vers '/shared/postgres_data/postgres_data_new' : impossible de supprimer la cible : Le répertoire n'est pas vide
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Génération des locales (cela peut prendre un certain temps)...
Aucune solution ne semble fonctionner. C’est tellement frustrant.
Il serait très inhabituel que quelqu’un propose un tel service sans qu’on le lui demande d’abord.
Si vous souhaitez engager quelqu’un, voici l’endroit où aller : Marketplace - Discourse Meta
Notre instance multi-sites est en panne après la mise à niveau. Elle indiquait :
Votre installation contient des extensions qui doivent être mises à jour
avec la commande ALTER EXTENSION. Le fichier
update_extensions.sql
lorsqu’il est exécuté par psql par le superutilisateur de la base de données mettra à jour
ces extensions.
Je ne trouve le fichier update_extensions.sql nulle part. Où pourrait-il se trouver ?
Vérifiez ceci
mv: impossible de déplacer '/shared/postgres_data' vers '/shared/postgres_data_old' : Périphérique ou ressource occupée
mv: déplacement inter-périphérique impossible : '/shared/postgres_data_new' vers '/shared/postgres_data/postgres_data_new' ; impossible de supprimer la cible : le répertoire n'est pas vide
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Génération des locales (cela pourrait prendre un certain temps)...
C’était moi. J’offre mon aide lorsqu’il semble que quelqu’un se trouve dans une situation qui sera difficile à résoudre avec l’aide ici.
Question de curiosité.
Existe-t-il une norme ou une stratégie concernant les mises à niveau des composants clés, comme Postgres ?
Je vois que le support de Postgres 13 s’est déroulé jusqu’au 25/11, que le support de la version 15 se déroulera jusqu’en 2027, et que la version actuelle est la 17.
Je cherche vraiment à apprendre et à comprendre. Changer de version de base de données est généralement une affaire importante et un travail considérable.
Merci !
Je suis là depuis PostgreSQL 10. En général, ils mettent à jour tous les deux versions, bien qu’ils soient passés de 12 à 13 parce que cette version apportait des améliorations qui valaient une transition anticipée. J’ai été un peu surpris qu’ils n’aillent pas jusqu’à la version 16.
En général, tout se passe assez bien si vous disposez de suffisamment d’espace disque et d’un docker récent.
Je suis revenu au modèle 13 en attendant un correctif, merci
J’ai résolu le problème que j’avais avec la mise à niveau de PostgreSQL de 13 à 15, après avoir restauré le serveur avec la mise à niveau échouée à partir des sauvegardes, les étapes suivantes ont fonctionné pour moi avec une locale PostgreSQL en_GB.UTF-8 :
sudo -i
su - discourse
cd /var/discourse
git stash
git stash drop
git pull
./launcher stop app
docker run --rm \
--entrypoint=/bin/bash \
-e LANG='en_GB.UTF-8' \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen & \
locale-gen & \
apt-get update & \
apt-get install -y postgresql-13-pgvector postgresql-15-pgvector & \
docker-upgrade'
exit
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
chown -R 101:104 /var/discourse/shared/standalone/postgres_data
su - discourse
cd /var/discourse
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data
./launcher rebuild app
J’ai dû supprimer les modifications locales qui avaient été apportées dans le passé pour la LANG PostgreSQL en utilisant git stash; git stash drop et le déplacement des répertoires de données PostgreSQL a dû être effectué en tant que root et un chown était nécessaire.
Est-ce que git pull est requis cette fois-ci ? Habituellement, ce n’est pas le cas.
Il n’est jamais nécessaire de nos jours, car la reconstruction s’en charge.
Le message final Device or resource busy (Périphérique ou ressource occupée) de la première erreur implique que quelque chose d’autre détient un verrou sur ce répertoire postgres_data et ne peut donc pas être déplacé.
Comme il s’agit du répertoire de la base de données, une explication probable est que postgres_data pourrait être un point de montage. C’est encore plus probable puisque nous voyons inter-device move failed (déplacement inter-périphériques impossible) dans la deuxième commande mv, ce qui implique que shared/postgres_data_new et shared/postgres_data sont sur des disques/partitions différents.
Si vous confirmez que postgres_data est un point de montage, vous devrez déplacer manuellement tous les fichiers hors de postgres_data vers un autre répertoire de sauvegarde, puis déplacer tous les fichiers de l’intérieur de postgres_data_new vers le répertoire postgres_data (maintenant vide). Les deux déplacements doivent être effectués après la fin de la première reconstruction avec UPGRADE OF POSTGRES COMPLETE mais avant de lancer la seconde.
Si postgres_data n’est pas un point de montage, lsof est votre ami. Vous pouvez l’utiliser pour essayer d’identifier ce qui cause le verrouillage.
Bien sûr, effectuez d’abord les sauvegardes nécessaires.
C’est parfait, merci.
Les fichiers se trouvaient dans le dossier suivant :
/var/postgres_data_discourse sous le nom de postgres_data_new
Ce qui suit l’a résolu :
J’ai déplacé postgres_data_new vers /var
J’ai renommé postgres_data_discourse en postgres_data_discourse_old
J’ai renommé postgres_data_new en postgres_data_discourse
J’ai exécuté ./launcher rebuild app
Merci encore 
J’ai 62 Go de base de données, que suggérez-vous pour effectuer la meilleure mise à niveau ?
62G /var/discourse/shared/standalone/postgres_data
Je vous recommande de migrer vers une nouvelle VM, de démarrer une nouvelle instance de Discourse avec une base de données vide (en copiant les répertoires ssl et letsencrypt si vous souhaitez une transition sans interruption) et de restaurer la base de données actuelle sur le nouveau serveur. Cela vous permettra d’effectuer la mise à niveau sans interruption et sans risque qu’un problème survienne.
Il n’est probablement pas trop tôt pour mettre à jour votre système d’exploitation de toute façon.
C’est une bonne idée.
Puis-je déplacer la sauvegarde de la version ### 3.4.0.beta4-dev vers ### la dernière version d’une nouvelle installation ?
Si vous demandez si vous pouvez restaurer n’importe quelle ancienne version de Discourse vers la nouvelle version que vous pourriez obtenir, la réponse est oui.