Irgendwo haben Sie also den Postgres-Port auf 50432 anstelle von 5432 geändert? (ODER vielleicht macht das der Migrationscode, und ich habe es nie bemerkt).
Vielleicht auf die Postgres13-Vorlage umsteigen, wie im OP (ursprünglicher Beitrag) vorgeschlagen? Und wenn das funktioniert, würde ich auf einen neuen Server umziehen und das ganze Problem des Übergangs zu einer neuen Postgres-Version vermeiden und einfach die Datenbank auf dem neuen Server wiederherstellen.
Ich habe nicht genügend Speicherplatz, um dieses Upgrade auf meiner Discourse-Partition durchzuführen. Ich habe jedoch viel Speicherplatz auf einem anderen Laufwerk. Gibt es eine Möglichkeit, dies für den temporären Speicher zu nutzen?
Es ist wahrscheinlich sowieso Zeit für ein OS-Upgrade, und der Umzug auf eine neue VM ist viel einfacher, erfordert wenig Ausfallzeiten, und wenn etwas schief geht, haben Sie immer noch einen funktionierenden Server.
Wenn Sie einen separaten Datencontainer haben, können Sie versuchen, /var/discourse/shared/data auf die andere Partition zu verschieben und die Volumes in Ihrer YML entsprechend anzupassen.
Und wenn Sie keinen separaten Container haben, können Sie so etwas tun, es ist nur komplizierter.
Ich habe ein ähnliches (dasselbe?) Problem. Hast du das erwähnte Log überprüft?
In meinem Fall: Als ich aktualisiert habe, hatte ich zuerst ein Problem, dass der App-Container (in meinem Fall nur Web) nicht neu erstellt wurde, weil ich RSS-Polling als benutzerdefiniertes Plugin hinzugefügt hatte und dies mit den neuen Standardeinstellungen zu kollidieren scheint. Nachdem ich das entfernt hatte, funktionierte es.
Aber dann gab es Probleme mit der fehlenden Vektorerweiterung. Das lag daran, dass ich den Datencontainer eine Weile nicht neu erstellt hatte. Ich habe es geschafft, ihn auf 13 zu bringen, aber jetzt bleibe ich bei laufender 13 stecken. Wenn ich meine data.yaml auf postgres.template oder postgres.15.template ändere, schlägt die Migration fehl.
Zuerst schlug sie mit “unclean shutdown” fehl, und mit den obigen Hinweisen konnte ich das beheben. Aber jetzt schlägt die Migration fehl, da anscheinend die 13er-Installation fehlt? Vielleicht hängt das mit Resten im /shared-Verzeichnis zusammen? (Ich habe bereits versucht, das Verzeichnis postgres_new zu bereinigen).
-----------------------------------------------------------------
pg_upgrade run on Fri Oct 17 09:54:37 2025
-----------------------------------------------------------------
command: "/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" -D "/shared/postgres_data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" 2>&1
waiting for server to start....2025-10-17 09:54:37.744 UTC [1900] LOG: starting PostgreSQL 13.22 (Debian 13.22-1.pgdg12+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
2025-10-17 09:54:37.749 UTC [1900] LOG: listening on Unix socket "/var/lib/postgresql/.s.PGSQL.50432"
2025-10-17 09:54:37.760 UTC [1900] LOG: could not open configuration file "/etc/postgresql/13/main/pg_hba.conf": No such file or directory
2025-10-17 09:54:37.760 UTC [1900] FATAL: could not load pg_hba.conf
2025-10-17 09:54:37.762 UTC [1900] LOG: database system is shut down
stopped waiting
pg_ctl: could not start server
Examine the log output.
Was ich wahrscheinlich tun würde, ist, mit dem alten Container (wenn Sie das herausfinden können) wieder auf PG13 umzusteigen, dann ein Backup zu erstellen und auf einen neuen Server zu verschieben (Sie brauchen wahrscheinlich sowieso ein neues Betriebssystem).
Es sieht so aus, als ob der Container, den Sie haben, in einem kaputten Zustand ist. Versucht er, mit der PG13-Vorlage neu zu erstellen? Möglicherweise müssen Sie den Postgres-Backup-Ordner nach postgres_data verschieben und wieder auf 13 umschalten, um die Dinge wieder zum Laufen zu bringen.
Ja, ich laufe derzeit mit dem PG13 Container. Ich habe ihn mehrmals neu erstellt. Ich habe sogar das hängende _new Verzeichnis bereinigt. Nur jedes Mal, wenn ich versuche, zu 15 oder der offiziellen unveränderten Vorlage zu wechseln, schlägt es fehl. Ich werde es bald manuell migrieren, wenn sich dies nicht von selbst behebt. Ich sehe nicht, wie das Betriebssystem hier relevant ist.
Ich würde Ihr Volume Mount so umstrukturieren, dass das gesamte Verzeichnis Shared oder shared/postgres auf demselben Volume liegt. Dann sind die Verzeichnisumbenennungen (die regelmäßig benötigt werden) kein Problem mehr.
Es hat möglicherweise nichts mit dem unmittelbaren Problem zu tun. Es ist oft der Fall, dass, wenn Sie Discourse lange genug betreiben, um ein Postgres-Upgrade zu benötigen, Sie wahrscheinlich auch ein Betriebssystem-Upgrade benötigen.
Der Umzug auf einen neuen Server ermöglicht es Ihnen, mit praktisch keiner Ausfallzeit und keinem Risiko, in einem fehlerhaften Zustand zu landen, umzuziehen.
Andererseits verliefen die meisten Upgrades, die ich mit meinem Skript (das nur das hier beschriebene tut) durchgeführt habe, problemlos.
Ich denke, Sie würden zum nicht versionierten wechseln und dann die beiden Rebuilds durchführen.
