Es gibt verschiedene Ansätze zum Aktualisieren von PostgreSQL, einige führen jedoch zu Ausfallzeiten. Wenn Sie Ausfallzeiten vermeiden möchten, verwenden Sie die Replikation zum Aktualisieren - je nach Szenario logisch oder physisch (Streaming). In diesem Artikel werden wir den Unterschied zwischen logischer und physischer Replikation in PostgreSQL untersuchen. Anschließend erfahren Sie ausführlich, wie Sie die Version mithilfe der logischen Replikation aktualisieren und dabei Ausfallzeiten der Anwendung vermeiden. Im nächsten Artikel wird die physische Replikation erläutert.
In früheren Artikeln haben wir bereits über PostgreSQL-Upgrade-Methoden ( Upgrade von PostgreSQL mit pg_dumpall und Upgrade von PostgreSQL mit pg_dump / pg_restore ) als Teil der Serie Upgrading or Migrating Old PostgreSQL Versions gesprochen . Beide Methoden schließen jedoch Ausfallzeiten nicht aus.
Logische Replikationstypen
Hier diskutieren wir zwei Arten der Replikation:
- Replikation zwischen PostgreSQL 10 und 11 mithilfe der integrierten logischen Replikation.
- Replikation zwischen PostgreSQL 9.4 (oder vor PG 11) und PostgreSQL 11 unter Verwendung der pglogischen Erweiterung.
Um Ausfallzeiten zu minimieren, können Sie mithilfe der Replikation ein Upgrade durchführen. Wenn alle relevanten Daten auf einen anderen neuesten PostgreSQL-Server repliziert werden, übertragen Sie die Anwendung einfach mit minimalen Ausfallzeiten auf den neuen Server - obwohl dies natürlich alles von der Komplexität des Anwendungsstapels abhängt.
Die logische Replikation in PostgreSQL ermöglicht es Benutzern, Tabellen selektiv zu replizieren und einen Sicherungsserver für Schreibvorgänge zu öffnen. Die physische Replikation in PostgreSQL erfolgt in Blöcken. In diesem Fall wird jede Datenbank im Assistenten auf den Sicherungsserver repliziert, auf den keine Schreibvorgänge zugreifen können. Als Nächstes werden wir das physische Replikations- Streaming aufrufen.
Wenn Sie die logische Replikation auf einem Standby-Server verwenden, können Sie die Replikation von mehreren Mastern aktivieren. Dies ist in Situationen nützlich, in denen Sie Daten aus mehreren PostgreSQL-Datenbanken (OLTP) auf einen einzelnen PostgreSQL-Server replizieren müssen, um Berichte zu erstellen und Daten zu speichern.
Der Hauptvorteil der logischen Replikation gegenüber dem Streaming besteht darin, dass Sie mit der logischen Replikation Änderungen von der alten Version von PostgreSQL auf die neue Version replizieren können. Die Stream-Replikation funktioniert nur, wenn der Master und der Sicherungsserver dieselbe Hauptversion haben. Im Idealfall sollten auch zusätzliche Versionen übereinstimmen.
Replikation zwischen PostgreSQL 10 und 11
Ab PostgreSQL 10 ist standardmäßig die logische Replikation verfügbar. Daher können Sie die PostgreSQL 10-Datenbank in PostgreSQL 11 problemlos replizieren. Die logische Replikation verwendet das Publish- und Subscribe-Modell. Der Knoten, der die Änderungen übermittelt, wird zum Herausgeber. Und der Knoten, der diese Änderungen abonniert, wird ein Abonnent. Pro Veröffentlichung können mehrere Abonnements vorhanden sein.
Posting
Eine Publikation ist ein Array von Änderungen, die von einer Gruppe von Tabellen erstellt wurden. Es wird als Änderungssatz oder Replikationssatz bezeichnet . Veröffentlichungen können nur Tabellen enthalten, aber keine anderen Objekte. DML in diesen Tabellen kann repliziert werden, DDL jedoch nicht.
In der Publikation können Sie auswählen, welcher DML-Typ repliziert werden soll: INSERT, DELETE, UPDATE oder ALL. Standardmäßig ist ALL ausgewählt. Die Tabelle muss eine Replikatkennung haben, um UPDATE- und DELETE-Operationen auf den Abonnenten zu replizieren. Mithilfe von Replikatkennungen können Sie Zeilen finden, die aktualisiert oder gelöscht werden.
Der Primärschlüssel der Tabelle ist die Standardreplikatkennung. Oder Sie können den Bezeichner zu einem eindeutigen Index mit NOT NULL-Werten machen. Wenn Sie keinen Primärschlüssel oder keinen eindeutigen Index mit NO NULL-Werten haben, setzen Sie replica_identity auf FULL. In diesem Fall verwendet Postgres die gesamte Zeichenfolge als Schlüssel. Das ist aber nicht sehr rational.
Wenn der Veröffentlichung nach einer UPDATE- oder DELETE-Operation standardmäßig eine Tabelle ohne Primärschlüssel und Replikat-ID hinzugefügt wird, können Fehler auftreten.
Abonnement
Ein Abonnent kann eine oder mehrere Veröffentlichungen abonnieren. Stellen Sie vor dem Hinzufügen eines Abonnements sicher, dass die replizierten Tabellen auf dem Abonnentenknoten erstellt wurden. Speichern Sie dazu nur die Schemata des Herausgebers an den Abonnenten.
Beispiel für eine logische Replikation
Das folgende Beispiel beschreibt die logische Replikation nur zwischen den PostgreSQL-Versionen 10 und 11.
Erstellen Sie eine Publikation auf der Publisher-Site. Fügen Sie der Publikation alle oder nur einige Tabellen hinzu.
-- For adding ALL Tables in Database CREATE PUBLICATION percpub FOR ALL TABLES; -- For adding Selected Tables in Database CREATE PUBLICATION percpub FOR TABLE scott.employee scott.departments;
Erstellen Sie auf der Abonnentenseite ein Abonnement für diese Publikation. Führen Sie einen DDL-Speicherauszug der Tabellen für den Abonnenten durch, bevor Sie das Abonnement erstellen, wie oben erwähnt.
$ pg_dump -h publisher_server_ip -p 5432 -d percona -Fc -s -U postgres | pg_restore -d percona -h subscriber_node_ip -p 5432 -U postgres CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=secret port=5432' PUBLICATION percpub;
Dieser Befehl kopiert auch vorhandene Daten in die Tabellen. Wenn Sie das Kopieren vorhandener Daten deaktivieren möchten, verwenden Sie den folgenden Befehl. Es werden nur die Änderungen am Herausgeber kopiert.
CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=oracle port=5432' PUBLICATION percpub WITH (copy_data = false);
Verfolgen Sie die Replikation mit dem folgenden Befehl im Herausgeberknoten:
$ psql \x select * from pg_stat_replication;
Replikation zwischen PostgreSQL 9.4 und PostgreSQL 11
Was tun mit Versionen vor PostgreSQL 10? Für die Versionen 9.4 bis 11 gibt es eine spezielle Erweiterung - pglogical . Mit pglogical können Sie PostgreSQL 9.4 auf zwei Arten auf PostgreSQL 11 replizieren.
Im Folgenden finden Sie allgemeine Anweisungen zum Einrichten der Replikation zwischen PG 9.4 und PG 11 mithilfe der pglogischen Erweiterung.
Schritt 1. Betrachten Sie pgserver_94 als Quellserver mit der Datenbank percona_94 unter PostgreSQL 9.4. Erstellen Sie die folgende Erweiterung.
Code
[pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical_origin" CREATE EXTENSION [pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical" CREATE EXTENSION
Schritt 2. Fügen Sie nun alle oder einige der Tabellen zum Schema oder zu mehreren Schemas zur Replikation hinzu. Im folgenden Beispiel wird ein Fehler angezeigt, da eine der Tabellen keinen Primärschlüssel hat.
[pgserver_94:] $psql -d percona_94 psql (9.4.21) Type "help" for help. percona_94=# SELECT pglogical.create_node(node_name := 'provider1',dsn := 'host=192.168.0.24 port=5432 dbname=percona_94'); create_node ------------- 2976894835 (1 row) percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); ERROR: table pgbench_history cannot be added to replication set default DETAIL: table does not have PRIMARY KEY and given replication set is configured to replicate UPDATEs and/or DELETEs HINT: Add a PRIMARY KEY to the table percona_94=# ALTER TABLE pgbench_history ADD PRIMARY KEY (tid,aid,delta); ALTER TABLE percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); replication_set_add_all_tables -------------------------------- t (1 row)
Schritt 3. Führen Sie auf dem Abonnentenknoten, dh in der PostgreSQL 11-Datenbank, die folgenden Befehle aus.
[pgserver_11:] $psql -d percona_11 psql (11.2) Type "help" for help. percona_11=# SELECT pglogical.create_node(node_name := 'subscriber1',dsn := 'host=127.0.0.1 port=5432 dbname=percona_11 password=secret'); create_node ------------- 330520249 (1 row) percona_11=# SELECT pglogical.create_subscription(subscription_name := 'subscription1',provider_dsn := 'host=192.168.0.24 port=5432 dbname=percona_94 password=secret'); create_subscription --------------------- 1763399739 (1 row)
Schritt 4. Überprüfen Sie anschließend den Replikationsstatus, indem Sie eine Anforderung an mehrere Tabellen senden, die pglogical immer aktualisiert:
percona_11=# select * from pglogical.local_sync_status; sync_kind | sync_subid | sync_nspname | sync_relname | sync_status | sync_statuslsn -----------+------------+--------------+------------------+-------------+---------------- f | 1763399739 | public | pgbench_accounts | r | 0/2EB7D48 f | 1763399739 | public | pgbench_history | r | 0/2EB7D48 f | 1763399739 | public | pgbench_tellers | r | 0/2EB7D48 f | 1763399739 | public | pgbench_branches | r | 0/2EB7D48 d | 1763399739 | | | r | 0/0 (5 rows) percona_11=# select * from pglogical.subscription; sub_id | sub_name | sub_origin | sub_target | sub_origin_if | sub_target_if | sub_enabled | sub_slot_name | sub_rep lication_sets | sub_forward_origins | sub_apply_delay ------------+---------------+------------+------------+---------------+---------------+-------------+----------------------------------------+---------------- -----------------------+---------------------+----------------- 1763399739 | subscription1 | 2976894835 | 330520249 | 2402836775 | 2049915666 | t | pgl_percona_11_provider1_subscription1 | {default,defaul t_insert_only,ddl_sql} | {all} | 00:00:00 (1 row)
Primärschlüsselauswahl
Im zweiten Schritt haben Sie gesehen, wie alle Tabellen im öffentlichen Schema zum Replikationssatz hinzugefügt wurden, indem Sie einen Primärschlüssel für eine Tabelle ohne einen erstellt haben. Ich habe möglicherweise den falschen Primärschlüssel für diese Tabelle ausgewählt, dies dient jedoch nur zur Demonstration. Stellen Sie bei der Auswahl eines Primärschlüssels sicher, dass dieser korrekt ist. Es muss eindeutig sein und Spalten verwenden, die keine NULL-Werte enthalten. Wenn Sie nicht den richtigen Primärschlüssel finden, kann dies zu Ausfallzeiten der Anwendung führen. Hier ist ein Beispiel für einen Fehler, der auftreten kann:
[pgserver_94:] $pgbench -c 10 -T 300 -n percona_94 Client 7 aborted in state 12: ERROR: duplicate key value violates unique constraint "pgbench_history_pkey" DETAIL: Key (tid, aid, delta)=(7, 63268, 2491) already exists.
Hier erfahren Sie, wie Sie mit pglogical eine Replikation zwischen der alten und der neuen Version von PostgreSQL erstellen. Wechseln Sie nach dem Einrichten der Replikation einfach die Anwendungen auf die neueste Version, damit die Ausfallzeit minimal ist.