Während des Upgrades erhielt ich Folgendes:
Stopping PostgreSQL 15 database server: mainError: Config owner (postgres:101) and data owner (runit-log:999) do not match, and config owner is not root … failed!
failed!
could not open version file “/shared/postgres_data/PG_VERSION”: Permission denied
Failure, exiting
Dies wurde behoben durch:
sudo ./launcher enter app
und dann:
chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
Ich befinde mich in einer Endlosschleife, die Datenbank wurde erfolgreich aktualisiert, aber wenn ich ./launcher rebuild app ausführe, dreht es sich nur im Kreis. Das Einzige, was ich sehen kann, ist Folgendes:
EDIT: Diese Nachricht habe ich gefunden…
mv: inter-device move failed: '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new'; unable to remove target: Directory not empty
Ihre Installation enthält Erweiterungen, die mit dem Befehl ALTER EXTENSION aktualisiert werden sollten. Die Datei
update_extensions.sql
wird, wenn sie von psql vom Datenbank-Superuser ausgeführt wird, diese Erweiterungen aktualisieren.
Bitte um Rat
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade.
Once you start the new server, consider running:
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
UPGRADE OF POSTGRES COMPLETE
Old 13 database is stored at /shared/postgres_data_old
To complete the upgrade, rebuild again using:
./launcher rebuild app
-------------------------------------------------------------------------------------
Ok, es scheint, dass hier das Problem liegt:
Diese befinden sich unter shared/standalone/ und wurden bereits manuell verschoben…
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old': Device or resource busy
mv: inter-device move failed: '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new'; unable to remove target: Directory not empty
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generating locales (this might take a while)...
Keine Lösung scheint zu funktionieren. Es ist so frustrierend.
Das wäre sehr ungewöhnlich, wenn jemand einen solchen Dienst einfach anbietet, ohne zuerst danach gefragt zu werden.
Wenn Sie jemanden einstellen möchten, ist dies der richtige Ort: Marketplace - Discourse Meta
Unsere Multi-Site-Instanz ist nach dem Upgrade ausgefallen. Es wurde angezeigt:
Ihre Installation enthält Erweiterungen, die mit dem Befehl ALTER EXTENSION aktualisiert werden sollten. Die Datei
update_extensions.sql
wird, wenn sie von psql vom Datenbank-Superuser ausgeführt wird, diese Erweiterungen aktualisieren.
Ich kann die Datei update_extensions.sql nirgends finden. Wo könnte sie sich befinden?
Überprüfen Sie dies
mv: kann '/shared/postgres_data' nicht nach '/shared/postgres_data_old' verschieben: Gerät oder Ressource belegt
mv: geräteübergreifendes Verschieben fehlgeschlagen: '/shared/postgres_data_new' nach '/shared/postgres_data/postgres_data_new'; Ziel kann nicht entfernt werden: Verzeichnis nicht leer
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Generiere Lokalisierungen (dies kann eine Weile dauern)...
Ich war es. Ich biete Hilfe an, wenn es den Anschein hat, dass jemand in einer Situation ist, die mit Hilfe hier schwer zu lösen sein wird.
Neugierige Frage.
Gibt es eine Standardmethode oder Strategie für Upgrades wichtiger Komponenten wie Postgres?
Ich sehe, dass die Unterstützung für Postgres 13 bis zum 25.11. lief, die für 15 bis 2027 und die aktuelle Version ist 17.
Ich möchte wirklich lernen und verstehen. Das Ändern von Datenbankversionen ist im Allgemeinen eine große Sache und eine schwere Aufgabe.
Danke!
Ich bin seit Postgres 10 dabei. Sie updaten normalerweise alle zwei Versionen, obwohl sie von 12 auf 13 gewechselt sind, weil es einige Verbesserungen gab, die einen frühen Umstieg lohnenswert machten. Ich war etwas überrascht, dass sie nicht auf 16 umgestiegen sind.
Sie laufen in der Regel ziemlich reibungslos, wenn man genug Festplattenspeicher und einen aktuellen Docker hat.
Ich bin bis zur Behebung des Problems zum 13-Template zurückgekehrt, danke
Ich habe das Problem mit dem Upgrade von PostgreSQL 13 auf 15 gelöst. Nachdem ich den Server mit dem fehlgeschlagenen Upgrade aus Backups wiederhergestellt hatte, funktionierten die folgenden Schritte für mich mit einem PostgreSQL en_GB.UTF-8-Locale:
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
Ich musste die lokalen Änderungen, die in der Vergangenheit für die PostgreSQL LANG vorgenommen wurden, mit git stash; git stash drop entfernen, und das Verschieben der PostgreSQL-Datenverzeichnisse musste als root erfolgen und ein chown war erforderlich.
Ist git pull dieses Mal erforderlich? Normalerweise ist es das nicht.
Es wird heutzutage nie benötigt, da der Wiederaufbau dies erledigt.
Die abschließende Meldung Device or resource busy vom ersten Fehler impliziert, dass etwas anderes eine Sperre für dieses postgres_data-Verzeichnis hält, sodass es nicht verschoben werden kann.
Da dies das Datenbankverzeichnis ist, ist eine wahrscheinliche Erklärung, dass postgres_data ein Mountpoint sein könnte. Dies ist umso wahrscheinlicher, da wir im zweiten mv-Befehl inter-device move failed sehen, was impliziert, dass shared/postgres_data_new und shared/postgres_data auf verschiedenen Festplatten/Partitionen liegen.
Wenn Sie bestätigen, dass postgres_data ein Mountpoint ist, müssen Sie alle Dateien manuell aus postgres_data in ein anderes Backup-Verzeichnis verschieben und dann alle Dateien aus postgres_data_new in das (jetzt leere) postgres_data-Verzeichnis verschieben. Beide Verschiebungen sollten nach Abschluss des ersten Rebuilds mit UPGRADE OF POSTGRES COMPLETE erfolgen, aber bevor der zweite Rebuild gestartet wird.
Wenn postgres_data kein Mountpoint ist, ist lsof Ihr Freund. Sie können damit versuchen zu identifizieren, was die Sperre verursacht.
Erstellen Sie natürlich zuerst die notwendigen Backups.
Das ist perfekt, danke.
Die Dateien befanden sich im folgenden Ordner:
/var/postgres_data_discourse als postgres_data_new
Das hat es behoben.
Ich habe postgres_data_new nach /var verschoben
Ich habe postgres_data_discourse in postgres_data_discourse_old umbenannt
Ich habe postgres_data_new in postgres_data_discourse umbenannt
Ich habe ./launcher rebuild app ausgeführt
Danke nochmal 
Ich habe 62 GB Speicherplatz, was schlagen Sie für das beste Upgrade vor?
62 GB /var/discourse/shared/standalone/postgres_data
Ich empfehle Ihnen, auf eine neue VM umzuziehen, eine neue Discourse-Instanz mit einer leeren Datenbank zu starten (Sie können die Verzeichnisse ssl und letsencrypt kopieren, wenn Sie einen unterbrechungsfreien Wechsel wünschen) und die aktuelle Datenbank auf den neuen Server wiederherzustellen. Dies ermöglicht es Ihnen, das Upgrade ohne Ausfallzeit und ohne Risiko durchzuführen, dass etwas schiefgeht.
Es ist wahrscheinlich sowieso nicht zu früh, Ihr Betriebssystem zu aktualisieren.
Das ist eine gute Idee.
Kann ich ein Backup von ### 3.4.0.beta4-dev ### auf eine Neuinstallation der neuesten Version verschieben?
Wenn Sie fragen, ob Sie eine alte Version von Discourse auf eine neue Version von Discourse wiederherstellen können, die Sie möglicherweise erhalten, lautet die Antwort ja.