WARNUNG! 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 gerade Änderungen eingeführt, um unser Docker-Image auf PostgreSQL 13 zu aktualisieren. Alle Site-Administratoren, die Discourse über die Befehlszeile neu aufbauen, werden von der vorherigen PostgreSQL 12 auf PostgreSQL 13 aktualisiert. Beachten Sie, dass, wenn Sie das Update auf PostgreSQL 12 im Mai nicht durchgeführt haben, Sie dieses Update überspringen und direkt zu PostgreSQL 13 wechseln können.
Wenn Sie das Update zuvor zurückgestellt haben, ändern Sie die PostgreSQL-Vorlage in app.yml von templates/postgres.10.template.yml zu templates/postgres.template.yml.
Wie bei jedem Upgrade wird dringend empfohlen, vor jeglichen Aktionen ein Backup zu erstellen.
Aktualisieren
Offizieller Installationsleitfaden (Single Container)
Beim nächsten Neuaufbau werden Sie am Ende folgende Meldung sehen:
-------------------------------------------------------------------------------------
UPGRADE OF POSTGRES COMPLETE
Old 12 database is stored at /shared/postgres_data_old
To complete the upgrade, rebuild again using:
./launcher rebuild app
-------------------------------------------------------------------------------------
Das bedeutet, dass das Upgrade erfolgreich verlaufen ist! Sie müssen nur einen neuen Neuaufbau durchführen, um Ihre Site wieder zum Laufen zu bringen.
Installation mit Daten-Container
Wenn Sie eine Einrichtung mit einem dedizierten Daten-Container verwenden, der auf dem in unserem discourse_docker-Repository bereitgestellten Beispiel basiert, müssen Sie sicherstellen, dass PostgreSQL sicher und sauber heruntergefahren wird.
Heutzutage laufen im Hintergrund Jobs, die Abfragen ausführen, 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 mit tail überprüfen, um zu sehen, ob es ordnungsgemäß heruntergefahren wurde.
Das Ausführen von tail -f shared/data/log/var-log/postgres/current sollte bei einem sauberen Herunterfahren 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 VOR DEM VERSUCH DIESER METHODE EIN BACKUP DER POSTGRES_DATA ERSTELLEN
Wenn Sie sich in einer Umgebung mit begrenztem Speicherplatz befinden und keinen Weg haben, mehr Speicherplatz zu erhalten, 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/12/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/13/data \
tianon/postgres-upgrade:12-to-13
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.
Verschieben 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.12.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 das neue PostgreSQL nicht über Tabellenstatistiken. Sie können diese mit folgenden Befehlen generieren:
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
VACUUM VERBOSE ANALYZE;
\q
exit
exit
Oder diese Einzeiler-Version davon:
/var/discourse/launcher run app "echo 'vacuum verbose analyze;' | su postgres -c 'psql discourse'"
Neu erstellen der Indizes
Das Hauptmerkmal dieses Upgrades ist eine erhebliche Speichereinsparung in unserer größten Tabelle in jeder Instanz, der post_timings-Tabelle und ihren Indizes. Nach einem erfolgreichen Update müssen Sie einen Befehl ausführen, um die Indizes neu zu erstellen und die Vorteile zu nutzen.
cd /var/discourse
./launcher enter app
su postgres
psql
\connect discourse
REINDEX SCHEMA CONCURRENTLY public;
\q
exit
exit
Wenn Sie die Größe von post_timings vor und nach dem REINDEX überprüfen können, wäre das eine coole Statistik, die Sie hier teilen können!
Sie können die folgende Abfrage verwenden, um die 20 größten Datenobjekte zu überprüfen. Führen Sie sie vor und nach dem Reindex aus:
WITH RECURSIVE pg_inherit(inhrelid, inhparent) AS
(select inhrelid, inhparent
FROM pg_inherits
UNION
SELECT child.inhrelid, parent.inhparent
FROM pg_inherit child, pg_inherits parent
WHERE child.inhparent = parent.inhrelid),
pg_inherit_short AS (SELECT * FROM pg_inherit WHERE inhparent NOT IN (SELECT inhrelid FROM pg_inherit))
SELECT table_schema
, TABLE_NAME
, row_estimate
, pg_size_pretty(total_bytes) AS total
, pg_size_pretty(index_bytes) AS INDEX
, pg_size_pretty(toast_bytes) AS toast
, pg_size_pretty(table_bytes) AS TABLE
FROM (
SELECT *, total_bytes-index_bytes-COALESCE(toast_bytes,0) AS table_bytes
FROM (
SELECT c.oid
, nspname AS table_schema
, relname AS TABLE_NAME
, SUM(c.reltuples) OVER (partition BY parent) AS row_estimate
, SUM(pg_total_relation_size(c.oid)) OVER (partition BY parent) AS total_bytes
, SUM(pg_indexes_size(c.oid)) OVER (partition BY parent) AS index_bytes
, SUM(pg_total_relation_size(reltoastrelid)) OVER (partition BY parent) AS toast_bytes
, parent
FROM (
SELECT pg_class.oid
, reltuples
, relname
, relnamespace
, pg_class.reltoastrelid
, COALESCE(inhparent, pg_class.oid) parent
FROM pg_class
LEFT JOIN pg_inherit_short ON inhrelid = oid
WHERE relkind IN ('r', 'p')
) c
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
) a
WHERE oid = parent
) a
ORDER BY total_bytes DESC LIMIT 20;
Bereinigen alter Daten
Für eine Standardinstallation können Sie die alten Daten im PG12-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 Sie ein Upgrade-Fehler mit der oben genannten Meldung erhalten, können Sie einen einfacheren Ansatz versuchen, um ihn wieder in einen besseren Zustand zu versetzen.
Starten Sie den alten Container mit ./launcher start app. Warten Sie einige Minuten, bis er wieder online ist.
Fahren Sie ihn nun erneut mit ./launcher stop app herunter. Überprüfen Sie danach die Logs, um zu sehen, ob es ein sauberes Herunterfahren war:
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 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 Sie nicht-standardmäßige Locales für Ihre Datenbank verwenden. Es wurde berichtet, dass 3 Variablen erforderlich sind, damit dies erfolgreich ist. Stellen Sie sicher, dass der env:-Abschnitt Ihrer 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
Ersetzen Sie en_US.UTF-8 durch Ihr lokales Setting.
Jeder Neuaufbau führt das Upgrade erneut durch (Upgrade-Schleife)
Wenn dies geschieht, enthalten Ihre Upgrade-Logs Folgendes:
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 Weitermachen an einen anderen Ort.
Vorschläge für Skripte nach Abschluss des Upgrades – Muss ich etwas tun?
Sobald das Upgrade abgeschlossen ist, sehen Sie eine Ausgabe der pg_upgrade-Meldung wie folgt:
Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh
Running this script will delete the old cluster's data files:
./delete_old_cluster.sh
Sie können diese Meldung sicher ignorieren.
Ich habe das PostgreSQL 12-Update übersprungen, was nun?
Sie können die Standardanweisungen am Anfang dieses Leitfadens befolgen; sie aktualisieren Ihre Version ohne Probleme auf 13.
Wenn Sie die Anweisungen für Umgebungen mit begrenztem Speicherplatz befolgen, passen Sie die Versionsnummern entsprechend an.
