ACHTUNG! Das Upgrade erfordert viel freien Festplattenspeicher (das 2-fache der Datenbankgröße).
Wir haben gerade Änderungen eingeführt, um unser Docker-Image auf PostgreSQL 18 zu aktualisieren. Site-Administratoren, die Discourse über die Kommandozeile neu aufbauen, werden von der vorherigen PostgreSQL 15-Version auf PostgreSQL 18 aktualisiert. Beachte, dass du das Upgrade überspringen und direkt auf PostgreSQL 18 aktualisieren kannst, wenn du das PostgreSQL 15-Update aus dem Jahr 2025 damals nicht durchgeführt hast.
Wenn du das Upgrade zuvor zurückgestellt hast, ändere die PostgreSQL-Vorlage in app.yml von templates/postgres.13.template.yml zu templates/postgres.template.yml.
Wie bei jedem Upgrade wird dringend empfohlen, vor Beginn ein Backup zu erstellen.
Änderungen an den Locale-Einstellungen
In der Vergangenheit kam es bei glibc-Updates, beispielsweise während Betriebssystem-Upgrades, zu Index-Korruptionen. Seit PostgreSQL 17 gibt es einen neuen eingebauten Locale-Provider, der unabhängig von der glibc des Betriebssystems ist und daher versionsübergreifend stabil bleibt. Im Rahmen dieses Upgrades wechseln wir zu diesem eingebauten Provider unter Verwendung des C.UTF-8-Locales. Dieses Locale verwendet die Codepoint-Reihenfolge, und wir empfehlen es aus den aforementioned Stabilitätsgründen.
Um die Locale-Änderung vorzunehmen, müssen wir zunächst einen neuen DB-Cluster mit dem eingebauten Locale-Provider erstellen und dann die DB in diesen Cluster dumpen und wiederherstellen. Aus diesem Grund sind die Festplattenspeicheranforderungen höher als bei früheren Upgrades, bei denen wir In-Place-Updates durchgeführt haben.
Aktualisierung
Offizielle Installationsanleitung (Single-Container)
Bei deinem nächsten Neuaufbau wirst du am Ende folgende Meldung sehen:
-------------------------------------------------------------------------------------
UPGRADE OF POSTGRES COMPLETE
Old 15 database is stored at /shared/postgres_data_old
To complete the upgrade, rebuild again using:
./launcher rebuild app
-------------------------------------------------------------------------------------
Das bedeutet, dass das Upgrade erfolgreich war! Du musst nur einen weiteren Neuaufbau durchführen, um deine Site wieder verfügbar zu machen.
Installation mit Data-Container
Wenn du eine Konfiguration mit einem dedizierten Data-Container basierend auf der in unserem discourse_docker-Repository bereitgestellten Vorlage betreibst, solltest du sicherstellen, dass PostgreSQL auf sichere und saubere Weise heruntergefahren wird.
Heutzutage laufen Hintergrundjobs, die Abfragen über mehrere Minuten ausführen, sodass das Herunterfahren des Web-Containers dazu beiträgt, dass der Data-Container sicher heruntergefahren wird.
./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only
Bevor du den ersten Neuaufbau des Data-Containers ausführst, kannst du das PostgreSQL-Log mit tail beobachten, um zu sehen, ob der Shutdown korrekt durchgeführt wurde.
Wenn du tail -f shared/standalone/log/var-log/postgres/current ausführst, solltest du bei einem sauberen Shutdown folgende Log-Einträge sehen:
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Aufschub des Updates
Wenn du das Update bei deinem nächsten Neuaufbau aufschieben möchtest, kannst du die PostgreSQL-Vorlage in deiner app.yml-Datei austauschen, indem du "templates/postgres.template.yml" durch "templates/postgres.15.template.yml" ersetzt.
Dies wird nicht empfohlen, da einige Site-Administratoren vergessen, die Änderung afterwards rückgängig zu machen.
Optionale Aufgaben nach dem Update
Optimieren der PostgreSQL-Statistiken
Nach dem Update verfügt das neue PostgreSQL noch nicht über Tabellenstatistiken. Du kannst diese mit folgendem Befehl generieren:
docker exec -u postgres app \
/usr/lib/postgresql/18/bin/vacuumdb -d discourse --analyze-in-stages
Bereinigung alter Daten
Für eine Standardinstallation kannst du die alten Daten im PG15-Format mit folgendem Befehl löschen:
cd /var/discourse
./launcher cleanup
Wenn du einen separaten Data-Container verwendest, musst du die Backup-Kopie wie folgt entfernen:
rm -fr /var/discourse/shared/data/postgres_data_old/
FAQ
Der Quell-Cluster wurde nicht sauber heruntergefahren
Wenn das Upgrade mit der oben genannten Meldung fehlschlägt, kannst du einen einfacheren Ansatz versuchen, um den Zustand zu verbessern.
Starte den alten Container mit ./launcher start app. Warte einige Minuten, bis er wieder hochgefahren ist.
Fahre ihn nun erneut mit ./launcher stop app herunter. Beobachte afterwards die Logs mit tail, um zu sehen, ob es ein sauberer Shutdown war:
tail -f shared/standalone/log/var-log/postgres/current
2025-01-24 09:19:06.437 UTC [37] LOG: received smart shutdown request
2025-01-24 09:19:06.444 UTC [37] LOG: background worker "logical replication launcher" (PID 54) exited with exit code 1
2025-01-24 09:19:06.446 UTC [49] LOG: shutting down
2025-01-24 09:19:06.468 UTC [37] LOG: database system is shut down
Wenn die Logs nicht anzeigen, dass die Datenbank heruntergefahren wurde, kannst du den alten Container erneut starten, mit ./launcher enter app darin arbeiten, diese Befehle ausführen und afterwards die Logs erneut beobachten.
export SVWAIT=300
sv stop nginx
sv stop unicorn
sv stop postgres
exit
Wenn die Logs wie oben aussehen, kannst du nun versuchen, das Upgrade erneut mit ./launcher rebuild app durchzuführen.
lc_collate-Werte für Datenbank “postgres” stimmen nicht überein
Dieser Fehler tritt auf, wenn du für deine Datenbank Nicht-Standard-Locales verwendest. Es wurde gemeldet, dass dafür 3 Variablen erforderlich sind. Stelle sicher, dass der env:-Bereich deiner app.yml-Datei die folgenden 3 Zeilen enthält:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
Ersetze en_US.UTF-8 durch dein Locale.
Jeder Neuaufbau führt das Upgrade erneut aus, also Upgrade-Schleife
Wenn dies geschieht, enthalten deine Upgrade-Logs
mv: cannot move '/shared/postgres_data' to '/shared/postgres_data_old/postgres_data': Directory not empty
mv: cannot move '/shared/postgres_data_new' to '/shared/postgres_data/postgres_data_new': Directory not empty
Das bedeutet, dass noch Dateien vom letzten Upgrade vorhanden sind. Verschiebe diese an einen anderen Ort, bevor du fortfährst.
Ich habe das PostgreSQL 15-Update übersprungen, was soll ich jetzt tun?
Du kannst die Standardanweisungen oben in dieser Anleitung befolgen, und sie werden dich von deiner Version auf 18 aktualisieren, ohne Probleme.
