In einem kürzlich erschienenen Blog über die Neuerungen in PostgreSQL 13 haben wir einige der neuen Funktionen dieser Version besprochen, aber jetzt sehen wir uns an, wie ein Upgrade durchgeführt wird, um alle diese erwähnten Funktionen nutzen zu können .
Upgrade auf PostgreSQL 13
Wenn Sie Ihre aktuelle PostgreSQL-Version auf diese neue aktualisieren möchten, haben Sie drei native Hauptoptionen, um diese Aufgabe auszuführen.
-
Pg_dump/pg_dumpall:Es ist ein logisches Backup-Tool, mit dem Sie Ihre Daten sichern und im wiederherstellen können neue PostgreSQL-Version. Hier haben Sie eine Ausfallzeit, die je nach Datengröße variiert. Sie müssen das System stoppen oder neue Daten im primären Knoten vermeiden, pg_dump ausführen, den generierten Dump auf den neuen Datenbankknoten verschieben und ihn wiederherstellen. Während dieser Zeit können Sie nicht in Ihre primäre PostgreSQL-Datenbank schreiben, um Dateninkonsistenzen zu vermeiden.
-
Pg_upgrade:Es ist ein PostgreSQL-Tool zum direkten Upgrade Ihrer PostgreSQL-Version. Es könnte in einer Produktionsumgebung gefährlich sein und wir empfehlen diese Methode in diesem Fall nicht. Wenn Sie diese Methode verwenden, werden Sie auch Ausfallzeit haben, aber wahrscheinlich wird sie erheblich kürzer sein als die Verwendung der vorherigen pg_dump-Methode.
-
Logische Replikation:Seit PostgreSQL 10 können Sie diese Replikationsmethode verwenden, mit der Sie größere Versions-Upgrades durchführen können null (oder fast null) Ausfallzeiten. Auf diese Weise können Sie in der letzten PostgreSQL-Version einen Standby-Knoten hinzufügen, und wenn die Replikation auf dem neuesten Stand ist, können Sie einen Failover-Prozess durchführen, um den neuen PostgreSQL-Knoten hochzustufen.
Sehen wir uns also diese Methoden eine nach der anderen an.
Mit pg_dump/pg_dumpall
Falls Ausfallzeiten kein Problem für Sie sind, ist diese Methode eine einfache Möglichkeit für ein Upgrade.
Um den Dump zu erstellen, können Sie Folgendes ausführen:
$ pg_dumpall > dump_pg12.outOder um einen Dump einer einzelnen Datenbank zu erstellen:
$ pg_dump world > dump_world_pg12.outDann können Sie diesen Dump auf den Server mit der neuen PostgreSQL-Version kopieren und wiederherstellen:
$ psql -f dump_pg12.out postgresDenken Sie daran, dass Sie während dieses Vorgangs Ihre Anwendung beenden oder vermeiden müssen, in Ihre Datenbank zu schreiben, da es sonst zu Dateninkonsistenzen oder einem potenziellen Datenverlust kommt.
Verwendung von pg_upgrade
Zuerst müssen Sie sowohl die neue als auch die alte PostgreSQL-Version auf dem Server installiert haben.
$ rpm -qa |grep postgres
postgresql13-contrib-13.3-2PGDG.rhel8.x86_64
postgresql13-server-13.3-2PGDG.rhel8.x86_64
postgresql13-libs-13.3-2PGDG.rhel8.x86_64
postgresql13-13.3-2PGDG.rhel8.x86_64
postgresql12-libs-12.7-2PGDG.rhel8.x86_64
postgresql12-server-12.7-2PGDG.rhel8.x86_64
postgresql12-12.7-2PGDG.rhel8.x86_64
postgresql12-contrib-12.7-2PGDG.rhel8.x86_64Dann können Sie zuerst pg_upgrade ausführen, um das Upgrade zu testen, indem Sie das Flag -c hinzufügen:
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data -c
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for system-defined composite types in user tables ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok
Checking for new cluster tablespace directories ok
*Clusters are compatible*Die Flaggen bedeuten:
-
-b:Das alte ausführbare PostgreSQL-Verzeichnis
-
-B:Das neue ausführbare PostgreSQL-Verzeichnis
-
-d:Das alte Datenbank-Cluster-Konfigurationsverzeichnis
-
-D:Das neue Datenbank-Cluster-Konfigurationsverzeichnis
-
-c:Nur Cluster prüfen. Es ändert keine Daten
Wenn alles gut aussieht, können Sie den gleichen Befehl ohne das Flag -c ausführen und es wird Ihren PostgreSQL-Server aktualisieren. Dazu müssen Sie zuerst Ihre aktuelle Version stoppen und den erwähnten Befehl ausführen.
$ systemctl stop postgresql-12
$ /usr/pgsql-13/bin/pg_upgrade -b /usr/pgsql-12/bin -B /usr/pgsql-13/bin -d /var/lib/pgsql/12/data -D /var/lib/pgsql/13/data
...
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.shWenn es fertig ist, können Sie, wie die Nachricht andeutet, diese Skripte verwenden, um den neuen PostgreSQL-Server zu analysieren und den alten zu löschen, wenn er sicher ist.
Logische Replikation verwenden
Die logische Replikation ist eine Methode zum Replizieren von Datenobjekten und deren Änderungen, basierend auf ihrer Replikationsidentität. Es basiert auf einem Publish-and-Subscribe-Modus, bei dem ein oder mehrere Abonnenten eine oder mehrere Publikationen auf einem Publisher-Knoten abonnieren.
Auf dieser Grundlage konfigurieren wir nun den Herausgeber, in diesem Fall den PostgreSQL 12-Server, wie folgt.
Bearbeiten Sie die Konfigurationsdatei postgresql.conf:
listen_addresses = '*'
wal_level = logical
max_wal_senders = 8
max_replication_slots = 4Bearbeiten Sie die Konfigurationsdatei pg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
host all rep1 10.10.10.141/32 md5Verwenden Sie dort die Teilnehmer-IP-Adresse.
Jetzt müssen Sie den Abonnenten, in diesem Fall den PostgreSQL 13-Server, wie folgt konfigurieren.
Bearbeiten Sie die Konfigurationsdatei postgresql.conf:
listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8Da dieses PostgreSQL 13 bald der neue primäre Knoten sein wird, sollten Sie in diesem Schritt die Parameter wal_level und archive_mode hinzufügen, um einen späteren Neustart des Dienstes zu vermeiden.
wal_level = logical
archive_mode = onDiese Parameter sind nützlich, wenn Sie eine neue Replik hinzufügen oder PITR-Sicherungen verwenden möchten.
Einige dieser Änderungen erfordern einen Neustart des Servers, also starten Sie sowohl den Herausgeber als auch den Abonnenten neu.
Jetzt müssen Sie im Herausgeber den Benutzer erstellen, der vom Abonnenten verwendet werden soll, um darauf zuzugreifen. Die Rolle, die für die Replikationsverbindung verwendet wird, muss das REPLICATION-Attribut haben und um die Ausgangsdaten kopieren zu können, benötigt sie auch das SELECT-Privileg auf die veröffentlichte Tabelle:
world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '********' REPLICATION;
CREATE ROLE
world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;
GRANTLassen Sie uns die Pub1-Publikation im Publisher-Knoten für alle Tabellen erstellen:
world=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATIONDa das Schema nicht repliziert wird, müssen Sie ein Backup in Ihrem PostgreSQL 12 erstellen und es in Ihrem PostgreSQL 13 wiederherstellen. Das Backup wird nur für das Schema erstellt, da die Informationen im Original repliziert werden übertragen.
Führen Sie in PostgreSQL 12 Folgendes aus:
$ pg_dumpall -s > schema.sqlFühren Sie in PostgreSQL 13 Folgendes aus:
$ psql -d postgres -f schema.sqlSobald Sie Ihr Schema in PostgreSQL 13 haben, müssen Sie das Abonnement erstellen und die Werte von host, dbname, user und password durch die Werte ersetzen, die Ihrer Umgebung entsprechen.
world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.140 dbname=world user=rep1 password=********' PUBLICATION pub1;
NOTICE: created replication slot "sub1" on publisher
CREATE SUBSCRIPTIONDas Obige startet den Replikationsprozess, der die anfänglichen Tabelleninhalte der Tabellen in der Veröffentlichung synchronisiert und dann mit der Replikation inkrementeller Änderungen an diesen Tabellen beginnt.
Um das erstellte Abonnement zu überprüfen, können Sie den Katalog pg_stat_subscription verwenden. Diese Ansicht enthält eine Zeile pro Abonnement für den Haupt-Worker (mit Null-PID, wenn der Worker nicht ausgeführt wird) und zusätzliche Zeilen für Worker, die die anfängliche Datenkopie der abonnierten Tabellen handhaben.
world=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid | 16421
subname | sub1
pid | 464
relid |
received_lsn | 0/23A8490
last_msg_send_time | 2021-07-23 22:42:26.358605+00
last_msg_receipt_time | 2021-07-23 22:42:26.358842+00
latest_end_lsn | 0/23A8490
latest_end_time | 2021-07-23 22:42:26.358605+00Um zu überprüfen, wann die anfängliche Übertragung abgeschlossen ist, können Sie die Variable srsubstate im Katalog pg_subscription_rel überprüfen. Dieser Katalog enthält den Status für jede replizierte Beziehung in jedem Abonnement.
world=# SELECT * FROM pg_subscription_rel;
srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+-----------
16421 | 16408 | r | 0/23B1738
16421 | 16411 | r | 0/23B17A8
16421 | 16405 | r | 0/23B17E0
16421 | 16402 | r | 0/23B17E0
(4 rows)Spaltenbeschreibungen:
-
srsubid:Verweis auf Abonnement.
-
srrelid:Verweis auf Beziehung.
-
srsubstate:Zustandscode:i =initialisieren, d =Daten werden kopiert, s =synchronisiert, r =bereit (normale Replikation).
-
srsublsn:End-LSN für s- und r-Zustände.
Wenn die anfängliche Übertragung abgeschlossen ist, haben Sie alles bereit, um Ihre Anwendung auf Ihren neuen PostgreSQL 13-Server zu verweisen.
Fazit
Wie Sie sehen können, bietet PostgreSQL je nach Ihren Anforderungen und Ihrer Toleranz gegenüber Ausfallzeiten verschiedene Upgrade-Optionen.
Egal welche Art von Technologie Sie verwenden, es ist eine notwendige, aber schwierige Aufgabe, Ihre Datenbankserver durch regelmäßige Upgrades auf dem neuesten Stand zu halten, da Sie sicherstellen müssen, dass Sie keinen Datenverlust erleiden oder Dateninkonsistenz nach dem Upgrade. Ein detaillierter und getesteter Plan ist hier der Schlüssel, und natürlich muss er für alle Fälle eine Rollback-Option beinhalten.
