PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

So aktualisieren Sie PostgreSQL 11 auf PostgreSQL 12 ohne Ausfallzeiten

Der intuitivste Weg für ein Datenbank-Upgrade, den Sie sich vorstellen können, besteht darin, ein Replikat in einer neuen Version zu erstellen und ein Failover der Anwendung darauf durchzuführen, und tatsächlich funktioniert es perfekt in anderen Engines. Mit PostgreSQL war dies bisher nativ nicht möglich. Um Upgrades durchzuführen, mussten Sie über andere Upgrade-Möglichkeiten nachdenken, wie z. B. die Verwendung von pg_upgrade, Dumping und Wiederherstellung oder die Verwendung einiger Tools von Drittanbietern wie Slony oder Bucardo, die alle ihre eigenen Einschränkungen haben. Dies liegt an der Art und Weise, wie PostgreSQL die Replikation implementiert hat.

Die PostgreSQL-Streaming-Replikation (die allgemeine PostgreSQL-Replikation) ist eine physische Replikation, die die Änderungen Byte für Byte repliziert und eine identische Kopie der Datenbank auf einem anderen Server erstellt. Diese Methode hat viele Einschränkungen, wenn Sie an ein Upgrade denken, da Sie einfach kein Replikat in einer anderen Serverversion oder sogar in einer anderen Architektur erstellen können.

Seit PostgreSQL 10 ist eine integrierte logische Replikation implementiert, die Sie im Gegensatz zur physischen Replikation zwischen verschiedenen Hauptversionen von PostgreSQL replizieren können. Dies öffnet natürlich eine neue Tür zum Upgraden von Strategien.

In diesem Blog werden wir sehen, wie Sie Ihr PostgreSQL 11 ohne Ausfallzeiten mithilfe der logischen Replikation auf PostgreSQL 12 aktualisieren können.

Logische PostgreSQL-Replikation

Die logische Replikation ist eine Methode zum Replizieren von Datenobjekten und deren Änderungen, basierend auf ihrer Replikationsidentität (normalerweise ein Primärschlüssel). Es basiert auf einem Publish-and-Subscribe-Modus, bei dem ein oder mehrere Abonnenten eine oder mehrere Publikationen auf einem Publisher-Knoten abonnieren.

Eine Veröffentlichung ist ein Satz von Änderungen, der aus einer Tabelle oder einer Gruppe von Tabellen generiert wird (auch als Replikationssatz bezeichnet). Der Knoten, in dem eine Veröffentlichung definiert ist, wird als Herausgeber bezeichnet. Ein Abonnement ist die Downstream-Seite der logischen Replikation. Der Knoten, an dem ein Abonnement definiert ist, wird als Abonnent bezeichnet und definiert die Verbindung zu einer anderen Datenbank und einem Satz von Veröffentlichungen (einer oder mehreren), die er abonnieren möchte. Abonnenten beziehen Daten aus den von ihnen abonnierten Publikationen.

Die logische Replikation basiert auf einer ähnlichen Architektur wie die physische Streaming-Replikation. Es wird durch die Prozesse "walsender" und "apply" implementiert. Der Walsender-Prozess startet die logische Dekodierung der WAL und lädt das standardmäßige Plug-in für die logische Dekodierung. Das Plugin wandelt die von WAL gelesenen Änderungen in das logische Replikationsprotokoll um und filtert die Daten gemäß der Veröffentlichungsspezifikation. Die Daten werden dann kontinuierlich unter Verwendung des Streaming-Replikationsprotokolls an den Apply-Worker übertragen, der die Daten lokalen Tabellen zuordnet und die einzelnen Änderungen, sobald sie empfangen werden, in einer korrekten Transaktionsreihenfolge anwendet.

Die logische Replikation beginnt mit der Erstellung eines Snapshots der Daten in der Publisher-Datenbank und Kopieren Sie diese an den Abonnenten. Die Anfangsdaten in den vorhandenen abonnierten Tabellen werden in einer parallelen Instanz eines speziellen Typs von Anwendungsprozessen abgespeichert und kopiert. Dieser Prozess erstellt einen eigenen temporären Replikationsslot und kopiert die vorhandenen Daten. Sobald die vorhandenen Daten kopiert sind, wechselt der Worker in den Synchronisationsmodus, der sicherstellt, dass die Tabelle in einen synchronisierten Zustand mit dem Hauptanwendungsprozess gebracht wird, indem alle Änderungen, die während der anfänglichen Datenkopie unter Verwendung der standardmäßigen logischen Replikation vorgenommen wurden, gestreamt werden. Sobald die Synchronisierung abgeschlossen ist, wird die Steuerung der Replikation der Tabelle an den Hauptanwendungsprozess zurückgegeben, wo die Replikation normal fortgesetzt wird. Die Änderungen am Herausgeber werden in Echtzeit an den Abonnenten gesendet.

So aktualisieren Sie PostgreSQL 11 auf PostgreSQL 12 mithilfe der logischen Replikation

Wir werden die logische Replikation zwischen zwei verschiedenen Hauptversionen von PostgreSQL (11 und 12) konfigurieren, und nachdem Sie dies zum Laufen gebracht haben, ist es natürlich nur noch eine Frage der Durchführung eines Anwendungs-Failovers in die Datenbank mit der neueren Version.

Wir werden die folgenden Schritte ausführen, um die logische Replikation zum Laufen zu bringen:

  • Konfigurieren Sie den Publisher-Knoten
  • Konfigurieren Sie den Abonnentenknoten
  • Erstellen Sie den Abonnenten-Benutzer
  • Erstellen Sie eine Veröffentlichung
  • Erstellen Sie die Tabellenstruktur im Abonnenten
  • Abonnement erstellen
  • Überprüfen Sie den Replikationsstatus

Also fangen wir an.

Auf Seiten des Herausgebers konfigurieren wir die folgenden Parameter in der Datei postgresql.conf:

  • listen_addresses: Welche IP-Adresse(n) zum Abhören. Wir verwenden '*' für alle.
  • wal_level: Legt fest, wie viele Informationen in die WAL geschrieben werden. Wir werden es auf „logisch“ setzen.
  • max_replication_slots :Gibt die maximale Anzahl von Replikationsslots an, die der Server unterstützen kann. Es muss mindestens auf die Anzahl der Abonnements gesetzt werden, die voraussichtlich eine Verbindung herstellen, plus etwas Reserve für die Tabellensynchronisierung.
  • max_wal_senders: Gibt die maximale Anzahl gleichzeitiger Verbindungen von Standby-Servern oder Streaming-Basis-Backup-Clients an. Es sollte mindestens auf den gleichen Wert wie max_replication_slots plus die Anzahl der physischen Replikate gesetzt werden, die gleichzeitig verbunden sind.

Beachten Sie, dass für einige dieser Parameter ein Neustart des PostgreSQL-Dienstes erforderlich war.

Die Datei pg_hba.conf muss ebenfalls angepasst werden, um die Replikation zu ermöglichen. Sie müssen dem Replikationsbenutzer erlauben, sich mit der Datenbank zu verbinden.

Auf dieser Grundlage konfigurieren wir den Herausgeber (in diesem Fall den PostgreSQL 11-Server) wie folgt:

postgresql.conf:

listen_addresses = '*'

wal_level = logical

max_wal_senders = 8

max_replication_slots = 4

​pg_hba.conf:

# TYPE  DATABASE        USER            ADDRESS                 METHOD

host     all     rep1     10.10.10.131/32     md5

Sie müssen den Benutzer (in diesem Beispiel rep1), der für die Replikation verwendet wird, und die IP-Adresse 10.10.10.131/32 für die IP ändern, die Ihrem PostgreSQL 12-Knoten entspricht.

Auf der Abonnentenseite müssen außerdem die max_replication_slots gesetzt werden. In diesem Fall sollte es mindestens auf die Anzahl der Abonnements eingestellt werden, die dem Abonnenten hinzugefügt werden.

Die anderen Parameter, die hier ebenfalls eingestellt werden müssen, sind:

  • max_logical_replication_workers :Gibt die maximale Anzahl logischer Replikationsworker an. Dies umfasst sowohl Anwendungsworker als auch Tabellensynchronisierungsworker. Logische Replikations-Worker werden aus dem durch max_worker_processes definierten Pool entnommen. Sie muss mindestens auf die Anzahl der Abonnements gesetzt werden, wieder plus etwas Reserve für die Tabellensynchronisierung.
  • max_worker_processes :Legt die maximale Anzahl von Hintergrundprozessen fest, die das System unterstützen kann. Er muss möglicherweise angepasst werden, um Replikationsworker aufzunehmen, mindestens max_logical_replication_workers + 1. Dieser Parameter erfordert einen PostgreSQL-Neustart.

Also müssen Sie den Abonnenten (in diesem Fall den PostgreSQL 12-Server) wie folgt konfigurieren:

postgresql.conf:

listen_addresses = '*'

max_replication_slots = 4

max_logical_replication_workers = 4

max_worker_processes = 8

Da dieses PostgreSQL 12 bald der neue primäre Knoten sein wird, sollten Sie in diesem Schritt die Parameter wal_level und archive_mode hinzufügen, um später einen erneuten Neustart des Dienstes zu vermeiden.

wal_level = logical

archive_mode = on

Diese Parameter sind nützlich, wenn Sie eine neue Replik hinzufügen oder PITR-Sicherungen verwenden möchten.

Im Herausgeber müssen Sie den Benutzer erstellen, mit dem sich der Abonnent verbindet:

world=# CREATE ROLE rep1 WITH LOGIN PASSWORD '*****' REPLICATION;

CREATE ROLE

Die für die Replikationsverbindung verwendete Rolle muss das REPLICATION-Attribut haben. Der Zugriff für die Rolle muss in pg_hba.conf konfiguriert sein und das LOGIN-Attribut haben.

Um die Ausgangsdaten kopieren zu können, muss die für die Replikationsverbindung verwendete Rolle das SELECT-Privileg auf eine veröffentlichte Tabelle haben.

world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep1;

GRANT

Wir erstellen pub1-Publikation im Publisher-Knoten für alle Tabellen:

world=# CREATE PUBLICATION pub1 FOR ALL TABLES;

CREATE PUBLICATION

Der Benutzer, der eine Veröffentlichung erstellt, muss das CREATE-Privileg in der Datenbank haben, aber um eine Veröffentlichung zu erstellen, die alle Tabellen automatisch veröffentlicht, muss der Benutzer ein Superuser sein.

Um die erstellte Veröffentlichung zu bestätigen, werden wir den Katalog pg_publication verwenden. Dieser Katalog enthält Informationen zu allen in der Datenbank angelegten Publikationen.

world=# SELECT * FROM pg_publication;

-[ RECORD 1 ]+-----

pubname      | pub1

pubowner     | 10

puballtables | t

pubinsert    | t

pubupdate    | t

pubdelete    | t

pubtruncate  | t

Spaltenbeschreibungen:

  • Pubname :Name der Veröffentlichung.
  • Pubowner :Eigentümer der Veröffentlichung.
  • Veröffentlichungstabellen :Wenn wahr, enthält diese Veröffentlichung automatisch alle Tabellen in der Datenbank, einschließlich derjenigen, die in Zukunft erstellt werden.
  • publizieren :Wenn wahr, werden INSERT-Vorgänge für Tabellen in der Veröffentlichung repliziert.
  • Veröffentlichungsaktualisierung :Wenn wahr, werden UPDATE-Vorgänge für Tabellen in der Veröffentlichung repliziert.
  • veröffentlichen :Wenn wahr, werden DELETE-Vorgänge für Tabellen in der Veröffentlichung repliziert.
  • veröffentlichen :Wenn wahr, werden TRUNCATE-Vorgänge für Tabellen in der Veröffentlichung repliziert.

Da das Schema nicht repliziert wird, müssen Sie ein Backup in PostgreSQL 11 erstellen und es in Ihrem PostgreSQL 12 wiederherstellen. Das Backup wird nur für das Schema erstellt, da die Informationen im Original repliziert werden übertragen.

In PostgreSQL 11:

$ pg_dumpall -s > schema.sql

In PostgreSQL 12:

$ psql -d postgres -f schema.sql

Sobald Sie Ihr Schema in PostgreSQL 12 haben, müssen Sie das Abonnement erstellen und die Werte von host, dbname, user und password durch die Werte ersetzen, die Ihrer Umgebung entsprechen.

PostgreSQL 12:

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=10.10.10.130 dbname=world user=rep1 password=*****' PUBLICATION pub1;

NOTICE:  created replication slot "sub1" on publisher

CREATE SUBSCRIPTION

Das 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.

Der Benutzer, der ein Abonnement erstellt, muss ein Superuser sein. Der Abonnementantragsprozess wird in der lokalen Datenbank mit den Rechten eines Superusers ausgeführt.

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                 | 16422

subname               | sub1

pid                   | 476

relid                 |

received_lsn          | 0/1771668

last_msg_send_time    | 2020-09-29 17:40:34.711411+00

last_msg_receipt_time | 2020-09-29 17:40:34.711533+00

latest_end_lsn        | 0/1771668

latest_end_time       | 2020-09-29 17:40:34.711411+00

Spaltenbeschreibungen:

  • subid :OID des Abonnements.
  • Untername :Name des Abonnements.
  • pid :Prozess-ID des Abonnement-Worker-Prozesses.
  • zuverlässig :OID der Relation, die der Worker synchronisiert; null für den Hauptanwendungsworker.
  • received_lsn :Letzte empfangene Position des Write-Ahead-Protokolls, wobei der Anfangswert dieses Felds 0 ist.
  • last_msg_send_time :Sendezeit der letzten vom Ursprungs-WAL-Absender empfangenen Nachricht.
  • last_msg_receipt_time :Empfangszeit der letzten vom ursprünglichen WAL-Absender empfangenen Nachricht.
  • latest_end_lsn :Letzter Write-Ahead-Protokollspeicherort, der an den ursprünglichen WAL-Absender gemeldet wurde.
  • latest_end_time :Zeitpunkt des letzten Write-Ahead-Protokollspeicherorts, der an den ursprünglichen WAL-Absender gemeldet wurde.

Um den Status der Replikation im Primärknoten zu überprüfen, können Sie pg_stat_replication:

verwenden 
world=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid              | 527

usesysid         | 16428

usename          | rep1

application_name | sub1

client_addr      | 10.10.10.131

client_hostname  |

client_port      | 35570

backend_start    | 2020-09-29 17:40:04.404905+00

backend_xmin     |

state            | streaming

sent_lsn         | 0/1771668

write_lsn        | 0/1771668

flush_lsn        | 0/1771668

replay_lsn       | 0/1771668

write_lag        |

flush_lag        |

replay_lag       |

sync_priority    | 0

sync_state       | async

Spaltenbeschreibungen:

  • pid :Prozess-ID eines WAL-Senderprozesses.
  • usesysid :OID des Benutzers, der bei diesem WAL-Senderprozess angemeldet ist.
  • Benutzername :Name des Benutzers, der bei diesem WAL-Senderprozess angemeldet ist.
  • Anwendungsname :Name der Anwendung, die mit diesem WAL-Sender verbunden ist.
  • client_addr :IP-Adresse des Clients, der mit diesem WAL-Sender verbunden ist. Wenn dieses Feld null ist, zeigt es an, dass der Client über einen Unix-Socket auf dem Server-Rechner verbunden ist.
  • client_hostname :Hostname des verbundenen Clients, wie von einem Reverse-DNS-Lookup von client_addr gemeldet. Dieses Feld ist nur für IP-Verbindungen ungleich Null und nur dann, wenn log_hostname aktiviert ist.
  • client_port :TCP-Portnummer, die der Client für die Kommunikation mit diesem WAL-Sender verwendet, oder -1, wenn ein Unix-Socket verwendet wird.
  • backend_start :Zeitpunkt, zu dem dieser Prozess gestartet wurde.
  • backend_xmin :xmin-Horizont dieses Standbys, gemeldet von hot_standby_feedback.
  • Zustand :Aktueller Status des WAL-Senders. Die möglichen Werte sind:Startup, Catchup, Streaming, Backup und Stoppen.
  • sent_lsn :Letzte Write-Ahead-Protokollposition, die auf dieser Verbindung gesendet wurde.
  • write_lsn :Letzte Write-Ahead-Protokollposition, die von diesem Standby-Server auf die Festplatte geschrieben wurde.
  • flush_lsn :Letzte Write-Ahead-Protokollposition, die von diesem Standby-Server auf die Festplatte geschrieben wurde.
  • replay_lsn :Letzte Write-Ahead-Protokollposition, die auf diesem Standby-Server in die Datenbank eingespielt wurde.
  • write_lag :Zwischen dem lokalen Leeren der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben hat (aber noch nicht geleert oder angewendet hat), ist Zeit vergangen.
  • flush_lag :Zwischen dem lokalen Leeren der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben und geleert (aber noch nicht angewendet) hat, verging Zeit.
  • replay_lag :Zwischen dem lokalen Leeren der letzten WAL und dem Erhalt der Benachrichtigung, dass dieser Standby-Server sie geschrieben, geleert und angewendet hat, ist Zeit vergangen.
  • sync_priority :Priorität dieses Standby-Servers für die Auswahl als synchroner Standby-Server in einer prioritätsbasierten synchronen Replikation.
  • sync_state :Synchronzustand dieses Standby-Servers. Die möglichen Werte sind async, potential, sync, quorum.

Um zu überprüfen, wann die anfängliche Übertragung abgeschlossen ist, können Sie das PostgreSQL-Protokoll auf dem Abonnenten überprüfen:

2020-09-29 17:40:04.403 UTC [476] LOG:  logical replication apply worker for subscription "sub1" has started

2020-09-29 17:40:04.411 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has started

2020-09-29 17:40:04.422 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has started

2020-09-29 17:40:04.516 UTC [477] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has finished

2020-09-29 17:40:04.522 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has started

2020-09-29 17:40:04.570 UTC [478] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has finished

2020-09-29 17:40:04.676 UTC [479] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has finished

Oder 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

---------+---------+------------+-----------

   16422 |   16386 | r          | 0/1771630

   16422 |   16392 | r          | 0/1771630

   16422 |   16399 | r          | 0/1771668

(3 rows)

Spaltenbeschreibungen:

  • srsubid :Hinweis auf Abonnement.
  • srrelid :Verweis auf Beziehung.
  • srsubstate :Zustandscode:i =initialisieren, d =Daten werden kopiert, s =synchronisiert, r =bereit (normale Replikation).
  • srsublsn :LSN für s- und r-Zustände beenden.

Sie können einige Testdatensätze in Ihr PostgreSQL 11 einfügen und überprüfen, ob Sie sie in Ihrem PostgreSQL 12 haben:

PostgreSQL 11:

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5001,'city1','USA','District1',10000);

INSERT 0 1

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5002,'city2','ITA','District2',20000);

INSERT 0 1

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5003,'city3','CHN','District3',30000);

INSERT 0 1

PostgreSQL 12:

world=# SELECT * FROM city WHERE id>5000;

  id  | name  | countrycode | district  | population

------+-------+-------------+-----------+------------

 5001 | city1 | USA         | District1 |      10000

 5002 | city2 | ITA         | District2 |      20000

 5003 | city3 | CHN         | District3 |      30000

(3 rows)

An diesem Punkt haben Sie alles bereit, um Ihre Anwendung auf Ihr PostgreSQL 12 zu verweisen.

Dazu müssen Sie zunächst bestätigen, dass Sie keine Replikationsverzögerung haben.

Auf dem primären Knoten:

world=# SELECT  application_name,  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) lag FROM pg_stat_replication;

-[ RECORD 1 ]----+-----

application_name | sub1

lag              | 0

Und jetzt müssen Sie nur noch Ihren Endpunkt von Ihrer Anwendung oder Ihrem Load Balancer (falls vorhanden) auf den neuen PostgreSQL 12-Server ändern.

Wenn Sie einen Load Balancer wie HAProxy haben, können Sie ihn so konfigurieren, dass PostgreSQL 11 als aktiv und PostgreSQL 12 als Backup verwendet wird:

Wenn Sie also einfach den alten primären Knoten in PostgreSQL 11 herunterfahren, der Backup-Server, in diesem Fall in PostgreSQL 12, beginnt den Datenverkehr auf transparente Weise für den Benutzer/die Anwendung zu empfangen.

Am Ende der Migration können Sie das Abonnement in Ihrem neuen primären Knoten in PostgreSQL 12 löschen:

world=# DROP SUBSCRIPTION sub1;

NOTICE:  dropped replication slot "sub1" on publisher

DROP SUBSCRIPTION

Und vergewissern Sie sich, dass es korrekt entfernt wurde:

world=# SELECT * FROM pg_subscription_rel;

(0 rows)

world=# SELECT * FROM pg_stat_subscription;

(0 rows)

Einschränkungen

Bevor Sie die logische Replikation verwenden, beachten Sie bitte die folgenden Einschränkungen:

  • Das Datenbankschema und die DDL-Befehle werden nicht repliziert. Das anfängliche Schema kann mit pg_dump --schema-only.
    • kopiert werden
  • Sequenzdaten werden nicht repliziert. Die Daten in seriellen oder Identitätsspalten, die von Sequenzen unterstützt werden, werden als Teil der Tabelle repliziert, aber die Sequenz selbst würde immer noch den Startwert des Abonnenten anzeigen.
  • Die Replikation von TRUNCATE-Befehlen wird unterstützt, aber beim Abschneiden von Tabellengruppen, die durch Fremdschlüssel verbunden sind, ist Vorsicht geboten. Beim Replizieren einer Kürzungsaktion kürzt der Abonnent dieselbe Gruppe von Tabellen, die auf dem Herausgeber gekürzt wurde, entweder explizit angegeben oder implizit über CASCADE erfasst, abzüglich Tabellen, die nicht Teil des Abonnements sind. Dies funktioniert ordnungsgemäß, wenn alle betroffenen Tabellen Teil desselben Abonnements sind. Wenn jedoch einige Tabellen, die auf dem Abonnenten gekürzt werden sollen, Fremdschlüsselverknüpfungen zu Tabellen haben, die nicht Teil desselben (oder eines beliebigen) Abonnements sind, schlägt die Anwendung der Kürzungsaktion auf dem Abonnenten fehl.
  • Große Objekte werden nicht repliziert. Dafür gibt es keine Problemumgehung, außer Daten in normalen Tabellen zu speichern.
  • Die Replikation ist nur von Basistabellen zu Basistabellen möglich. Das heißt, die Tabellen auf der Veröffentlichungs- und auf der Abonnementseite müssen normale Tabellen sein, keine Ansichten, materialisierten Ansichten, Partitionsstammtabellen oder Fremdtabellen. Im Fall von Partitionen können Sie eine Partitionshierarchie eins zu eins replizieren, aber Sie können derzeit nicht auf eine anders partitionierte Einrichtung replizieren.

Fazit

Ihren PostgreSQL-Server durch regelmäßige Upgrades auf dem neuesten Stand zu halten, war bis zur Version PostgreSQL 10 eine notwendige, aber schwierige Aufgabe. Glücklicherweise ist es dank logischer Replikation jetzt eine andere Geschichte.

In diesem Blog haben wir eine kurze Einführung in die logische Replikation gegeben, ein PostgreSQL-Feature, das nativ in Version 10 eingeführt wurde, und wir haben Ihnen gezeigt, wie es Ihnen helfen kann, dieses Upgrade von PostgreSQL 11 auf PostgreSQL 12 mit einer Strategie ohne Ausfallzeiten zu bewältigen.