Je rencontre l’erreur suivante en essayant de relancer une reconstruction pour passer à la dernière version testée. Cela inclurait de passer la version de postgres de 13 à 15.
[2025-03-12T20:49:22.045226 #1] INFO -- : Remplacement de (?-mix:^#local +replication +postgres +peer$) par local replication postgres peer dans /etc/postgresql/15/main/pg_hba.conf
I, [2025-03-12T20:49:22.045431 #1] INFO -- : Remplacement de (?-mix:^host.*all.*all.*127.*$) par host all all 0.0.0.0/0 md5 dans /etc/postgresql/15/main/pg_hba.conf
I, [2025-03-12T20:49:22.045624 #1] INFO -- : Remplacement de (?-mix:^host.*all.*all.*::1\\/128.*$) par host all all ::/0 md5 dans /etc/postgresql/15/main/pg_hba.conf
I, [2025-03-12T20:49:22.045816 #1] INFO -- : > 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
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
W: https://dl.yarnpkg.com/debian/dists/stable/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
debconf: delaying package configuration, since apt-utils is not installed
cp: cannot stat '/etc/postgresql/13/main/*': No such file or directory
Le script reste bloqué sur cette commande de copie.
Lorsque j’essaie de redémarrer le forum, la commande de redémarrage se termine avec succès mais le forum affiche “connection refused”.
Comment puis-je soit revenir à ma sauvegarde en postgres 13, soit avancer ? Merci.
Le conteneur de redémarrage n’a pas pu s’exécuter car il se trouvait dans un état intermittent entre les versions de la base de données. J’ai supprimé le dossier postgres_data et je restaure maintenant à partir de la sauvegarde.
Si vous utilisez effectivement un ancien système d’exploitation et une ancienne version de Docker, je vous recommande de mettre à jour les deux avant de réessayer la reconstruction.
Étiez-vous en train de mettre à jour une base de données volumineuse ? Si c’est le cas, il est possible que la mise à jour soit toujours en cours. Pendant la reconstruction, vous pouvez comparer périodiquement la taille des répertoires postgres_data et postgres_data_new. Si la taille de postgres_data_new continue de croître, la mise à jour est toujours en cours. (Vous pouvez également vérifier si la commande pg_upgrade est en cours d’exécution à partir de la liste des processus.)
Vous pouvez ignorer cette erreur cp pour le moment. J’ai pu mettre à jour un site de test sur une installation standard même avec la même erreur. (Elle a été causée par un changement en amont, nous corrigerons donc l’image pour supprimer l’erreur, mais cela ne devrait pas casser les mises à jour de la base de données, sauf si les configurations postgresql ont été modifiées de manière significative auparavant.)
oui, j’ai pu restaurer le site. Nous mettions effectivement à jour une grande base de données, mais je surveillais les répertoires ci-dessus pour m’assurer que postgres_data_new grandissait. Après un certain temps, elle n’a plus grandi, et le script s’est simplement bloqué sur cette commande.
Notre configuration était assez standard, à part la grande taille de la base de données. Je vais rassembler les détails et les posterai plus tard aujourd’hui.