ACHTUNG! Wenn Ihre Datenbank sehr groß ist, benötigen Sie viel zusätzlichen Festplattenspeicher (das 2-fache der Datenbankgröße) und sollten bei diesem Upgrade äußerst vorsichtig sein!
Wir haben das lang erwartete Upgrade auf eine neue Hauptversion von PostgreSQL erfolgreich abgeschlossen. Alle Site-Administratoren, die Discourse über die Befehlszeile neu aufbauen, werden von der alten PostgreSQL 10 auf PostgreSQL 12 aktualisiert.
Wir führen diese neue Version bereits seit einiger Zeit auf Meta aus, und alles funktioniert einwandfrei. PostgreSQL 12 bringt zahlreiche Verbesserungen mit sich, die von Discourse automatisch genutzt werden.
Aktualisierung
Offizieller Installationsleitfaden (Single Container)
Beim nächsten Neuaufbau werden Sie am Ende folgende Meldung sehen:
Upgrade abgeschlossen
----------------
Um das Upgrade abzuschließen, führen Sie erneut einen Neuaufbau durch:
./launcher rebuild app
-------------------------------------------------------------------------------------
Das bedeutet, dass beim Upgrade alles gut gelaufen ist! Sie müssen lediglich einen neuen Neuaufbau durchführen, um Ihre Site wieder zum Laufen zu bringen.
Installation mit Daten-Container
Wenn Sie ein Setup mit einem dedizierten Daten-Container verwenden, der auf dem in unserem discourse_docker-Repository bereitgestellten Beispiel basiert, sollten Sie sicherstellen, dass PostgreSQL sicher und sauber heruntergefahren wird.
Heutzutage laufen Hintergrundjobs mit Abfragen, die mehrere Minuten dauern. Das Herunterfahren des Web-Containers hilft daher, den Daten-Container sicher herunterzufahren.
./launcher stop web_only
./launcher stop data
./launcher rebuild data
./launcher rebuild data
./launcher rebuild web_only
Bevor Sie den ersten Neuaufbau für den Daten-Container ausführen, können Sie das PostgreSQL-Log verfolgen, um zu prüfen, ob es ordnungsgemäß heruntergefahren wurde.
Die Ausführung von tail -f shared/data/log/var-log/postgres/current sollte bei einem sauberen Vorgang folgende Logausgabe liefern:
2020-05-13 18:33:33.457 UTC [36] LOG: received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG: worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG: shutting down
2020-05-13 18:33:33.479 UTC [36] LOG: database system is shut down
Manuelles Update / Umgebungen mit begrenztem Speicherplatz
SIE MÜSSEN DIE POSTGRES_DATA SICHERN, BEVOR SIE DIES VERSUCHEN
Wenn Sie sich in einer Umgebung mit begrenztem Speicherplatz befinden, in der Sie keinen zusätzlichen Speicherplatz erhalten können, können Sie Folgendes versuchen:
./launcher stop app #(oder sowohl web_only als auch data, falls dies auf Sie zutrifft)
mkdir -p /var/discourse/shared/standalone/postgres_data_new
docker run --rm \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/10/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/12/data \
tianon/postgres-upgrade:10-to-12
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
./launcher rebuild app #(oder zuerst data und dann web_only, falls dies auf Sie zutrifft)
Bei meinen Tests benötigt dieses Verfahren weniger als das 1-fache Ihrer aktuellen Datenbankgröße an freiem Speicherplatz.
Aufschieben des Updates
Wenn Sie das Update beim nächsten Neuaufbau verschieben müssen, können Sie die PostgreSQL-Vorlage in Ihrer app.yml-Datei ändern, indem Sie \"templates/postgres.template.yml\" in \"templates/postgres.10.template.yml\" ändern.
Dies wird nicht empfohlen, da einige Site-Administratoren vergessen, die Änderung anschließend rückgängig zu machen.
Optionale Aufgaben nach dem Update
Optimierung der PostgreSQL-Statistiken
Nach dem Update verfügt die neue PostgreSQL-Version noch nicht über Tabellenstatistiken. Sie können diese wie folgt generieren:
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit
Oder diese Einzeiler-Version des Obigen:
/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"
Bereinigung alter Daten
Für eine Standardinstallation können Sie die alten Daten im PG10-Format mit dem folgenden Befehl löschen:
cd /var/discourse
./launcher cleanup
Wenn Sie einen separaten Daten-Container verwenden, müssen Sie die Sicherungskopie wie folgt entfernen:
rm -fr /var/discourse/shared/data/postgres_data_old/
FAQ
Der Quellcluster wurde nicht sauber heruntergefahren
Wenn das Upgrade mit der oben genannten Meldung fehlschlägt, können Sie einen einfacheren Ansatz versuchen, um ihn in einen besseren Zustand zu versetzen.
Starten Sie den alten Container mit ./launcher start app neu. Warten Sie ein paar Minuten, bis er wieder hochgefahren ist.
Fahren Sie ihn nun erneut mit ./launcher stop app herunter. Überprüfen Sie danach die Logs, um festzustellen, ob es sich um einen sauberen Vorgang handelte:
tail -f shared/data/log/var-log/postgres/current
2020-05-13 18:33:33.457 UTC [36] LOG: received smart shutdown request
2020-05-13 18:33:33.464 UTC [36] LOG: worker process: logical replication launcher (PID 52) exited with exit code 1
2020-05-13 18:33:33.465 UTC [47] LOG: shutting down
2020-05-13 18:33:33.479 UTC [36] LOG: database system is shut down
Wenn die Logs wie oben aussehen, können Sie nun erneut versuchen, das Upgrade mit ./launcher rebuild app durchzuführen.
lc_collate-Werte für die Datenbank "postgres" stimmen nicht überein
Dieser Fehler tritt auf, wenn Sie nicht standardmäßige Lokales für Ihre Datenbank verwenden. Es wurde berichtet, dass drei Variablen erforderlich sind, damit dies erfolgreich ist. Stellen Sie sicher, dass der Abschnitt env: Ihrer app.yml-Datei die folgenden drei Zeilen enthält:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
Ersetzen Sie en_US.UTF-8 durch Ihre eigene Lokale.
Jeder Neuaufbau führt das Upgrade erneut durch (Upgrade-Schleife)
Wenn dies geschieht, enthalten Ihre Upgrade-Logs folgende Meldungen:
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
Dies bedeutet, dass noch Dateien vom letzten Upgrade vorhanden sind. Verschieben Sie diese vor dem Fortfahren an einen anderen Ort.