Auf dieser Seite wird AlloyDB Omni-Version 15.5.4 mit der Kubernetes-Bereitstellungsoption dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Diese Seite wurde von der Cloud Translation API übersetzt.

Switchover und Failover mit der pglogical-Replikation

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite finden Sie Informationen zum Switchover und Failover mit pglogical-Replikation.

Hinweise

Nachdem die pglogical-Replikation eingerichtet wurde und eine praktikable Lösung für Hochverfügbarkeit (High Availability, HA) und Notfallwiederherstellung (Disaster Recovery, DR) vorhanden ist, und da die logische Replikation keine true und umfassende Replikation aller Datenbankobjekte bietet, müssen Sie diese Konfiguration testen, bevor Sie sie verwenden.

Weitere Informationen zur Erweiterung pglogical finden Sie unter pglogical.

Informationen zur Datenreplikation mit pglogical finden Sie unter Daten zwischen AlloyDB for PostgreSQL und AlloyDB Omni replizieren und Daten zwischen AlloyDB Omni und anderen Datenbanken replizieren.

Switchover mit pglogical-Replikation

Ein Switchover ist ein kontrollierter Prozess, mit dem die Rollen zwischen den Datenbanken des Anbieters und des Abonnenten getauscht werden. Wenn Sie einen Switchover durchführen, werden die Rollen der beiden Datenbanken (Anbieter und Abonnent) umgekehrt. Der Anbieter wird zum Abonnenten und der Abonnent zum Anbieter.

Diese Switchover-Funktion ist wichtig für Betriebssystem-Upgrades, PostgreSQL-Upgrades oder Failover-Tests.

Um dies in unidirektionalen Replikationskonfigurationen zu erreichen, müssen Sie eine neue Provider-/Subscriber-Beziehung einrichten und die alte Provider-/Subscriber-Beziehung entfernen.

Neue Anbieter-/Abonnentenkonfiguration erstellen

Verhindern Sie, dass die Anwendung in das Anbietersystem schreibt, um weitere Datenbankänderungen zu verhindern, und prüfen Sie die Replikationsverzögerung, um sicherzustellen, dass alle Transaktionen auf dem Abonnentenknoten wiedergegeben werden:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Wenn in allen Verzögerungsfeldern null angezeigt wird, ist die Replikation auf dem neuesten Stand und die Datenbank ist für ein Switchover bereit.

Die Ausgabe sieht etwa so aus:

-[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

Abonnentendatenbank in eine Anbieterdatenbank umwandeln:
1. Beenden Sie das bestehende Abo des Abonnenten.
2. Fügen Sie bei Bedarf das Replikationsset hinzu.
3. Fügen Sie dem Replikationssatz die erforderlichen Tabellen hinzu.
4. Erstelle ein neues Abonnentenabo in der neuen Abonnentendatenbank.
5. Leiten Sie die Anträge an den neuen Anbieter weiter.
Beende das Abo in der bestehenden Abonnentendatenbank, die zum neuen Anbieter wird:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
Optional: Erstellen Sie ein Replikationsset, das der Definition der ursprünglichen Anbieterdatenbank entspricht. Dies ist nicht erforderlich, wenn Sie die Standardreplikationssets verwenden:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Fügen Sie diesem Replikationssatz Tabellen hinzu:
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
Ersetzen Sie Folgendes:
- REPLICATION_SET_NAME: Der Name des Replikationssets.
- TABLE_NAME: Der Tabellenname eines Schema-Inhabers. Beispiel: ARRAY['public'].`

Erstellen Sie in der neuen Abonnentendatenbank, die zuvor die Anbieterdatenbank war, das neue Abo mit der Option synchronize_data auf false, um das anfängliche Laden der Tabelle zu verhindern:

SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

Prüfen Sie, ob das Abo auf dem Anbieternode funktioniert:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Wenn die Replikation funktioniert, ändern Sie die Verbindungsstrings der Anwendung, um die neue Anbieterdatenbank zu verwenden, und starten Sie die Anwendungsebenen neu.

Wenn Sie die Daten auf dem alten Providerknoten ändern, nachdem der Abonnent beendet wurde, werden diese Änderungen nicht repliziert und es kommt zu Datenverlust. Wenn in der ursprünglichen Anbieterdatenbank nicht replizierte Datenänderungen vorhanden sind oder der ursprüngliche Anbieter, also der neue Abonnent, sich nicht in einem Zustand befindet, der mit der neuen Anbieterdatenbank, also dem alten Abonnenten, übereinstimmt, müssen Sie die neue Abonnentendatenbank vollständig erstellen.

Alten Anbieter und altes Abo entfernen

Wenn Sie eine unidirektionale Replikation wünschen, müssen Sie die alte Provider-/Subscriber-Konfiguration entfernen.

Altes Abo beim neuen Anbieter kündigen:

SELECT pglogical.drop_subscription('<subscription name>')

Entfernen Sie den Replikationssatz auf dem neuen Abonnenten oder entfernen Sie alle Tabellen aus dem Replikationssatz:

SELECT pglogical.drop_replication_set('<replication set name>')

SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

Bidirektionale Replikation

Wenn Sie ohne Ausfallzeit umstellen oder sicherstellen möchten, dass keine Daten aufgrund ungeplanter Datenänderungen verloren gehen, müssen Sie die bidirektionale Replikation verwenden. Wenn Sie die bidirektionale Replikation implementieren, sollten Sie die Konfliktlösung in Betracht ziehen, sofern keine strengen Kontrollen vorhanden sind, um gleichzeitigen Schreibzugriff auf beide Knoten zu verhindern.

Sie können die Konfiguration für die Konfliktlösung mit den folgenden pglogical.conflict_resolution-Einstellungen einrichten:

error: Der Abonnent wird beendet, wenn ein Konflikt erkannt wird.
apply_remote: Die eingehenden Änderungen werden immer angewendet, unabhängig von den Daten in der Abonnentendatenbank. Dies ist die Standardeinstellung.
keep_local: Die in Konflikt stehenden eingehenden Daten werden immer ignoriert und die in Konflikt stehende Änderung wird verworfen.
last_update_wins: Die Version der Daten mit dem neuesten Commit-Zeitstempel ist die Version, die committet wird.
first_update_wins: Die Version der Daten mit dem ältesten Zeitstempel ist die Version, die übernommen wird.

Wenn Sie die bidirektionale Replikation einrichten möchten, müssen Sie den Anbieter und den Abonnenten so konfigurieren, dass die Replikation in beide Richtungen erfolgt. Der ursprüngliche Abonnent wird auch zu einem Anbieter mit demselben Replikationssatz wie der ursprüngliche Anbieter. Unter Tabelle erstellen und dem Standardreplikationssatz in der AlloyDB for PostgreSQL-Anbieterdatenbank hinzufügen finden Sie Informationen zum Erstellen eines Replikationssatzes, der den ursprünglichen Replikationssatz in der ursprünglichen Anbieterdatenbank dupliziert.

Sie müssen beim ursprünglichen Anbieter einen neuen Abonnenten hinzufügen. Informationen zum Erstellen eines neuen Abonnenten finden Sie unter Knoten und Abo in der AlloyDB Omni-Abonnentendatenbank erstellen. Achten Sie darauf, dass der Parameter synchronize_data für den Befehl pglogical.create_subscription auf false gesetzt ist. Dadurch wird das anfängliche Kopieren der Daten in die Tabelle vermieden.

Failover mit pglogical-Replikation

Ein Failover tritt ein, wenn die Anbieterdatenbank aus irgendeinem Grund nicht mehr verfügbar ist. In diesem Fall müssen Sie die Anwendung so umstellen, dass die Abonnentendatenbank verwendet wird.

Damit keine doppelten Daten versehentlich auf die Subscriber-Datenbank angewendet werden, die auf den Failover-Server verschoben wurde, müssen Sie das Abo deaktivieren. So wird verhindert, dass Änderungen eines wiederhergestellten Anbieters versehentlich angewendet werden, wenn der Anbieter wieder verfügbar ist.

Abonnenten test_sub_1 beenden:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Prüfen Sie, ob der Status auf disabled gesetzt ist:

SELECT pglogical.show_subscription_status('test_sub_1');