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

Switchover und Failover mit der pglogical-Replikation

Wählen Sie eine Dokumentenversion aus:

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

Hinweis

Nachdem die pglogical Replikation eingerichtet wurde und eine praktikable Lösung für Hochverfügbarkeit (HA) und Notfallwiederherstellung (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 pglogical-Erweiterung finden Sie unter About 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 Anbieter- und Abonnentendatenbanken gewechselt 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 Anbieter-/Abonnentenbeziehung einrichten und die alte Anbieter-/Abonnentenbeziehung entfernen.

Neue Anbieter-/Abonnentenkonfiguration erstellen

Verhindern Sie, dass die Anwendung in das Anbietersystem schreibt, um weitere Datenbankänderungen zu vermeiden, 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 einen 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 vorhandene Abonnentenabo.
2. Fügen Sie bei Bedarf den Replikationssatz hinzu.
3. Fügen Sie dem Replikationssatz die erforderlichen Tabellen hinzu.
4. Erstellen Sie ein neues Abonnentenabo in der neuen Abonnentendatenbank.
5. Leiten Sie die Anwendungen an den neuen Anbieter weiter.
Beenden Sie das Abo in der vorhandenen Abonnentendatenbank, die zum neuen Anbieter wird:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
Optional: Erstellen Sie einen Replikationssatz, der der Definition der ursprünglichen Anbieterdatenbank entspricht. Dies ist nicht erforderlich, wenn Sie die Standardreplikationssätze 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 Replikationssatzes.
- 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 Anbieterknoten 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 Anbieterknoten ändern, nachdem der Abonnent beendet wurde, werden diese Änderungen nicht repliziert und es kommt zu Datenverlust. Wenn es nicht replizierte Datenänderungen in der ursprünglichen Anbieterdatenbank gibt oder wenn der ursprüngliche Anbieter, der der neue Abonnent ist, sich nicht in einem Zustand befindet, der mit der neuen Anbieterdatenbank (dem alten Abonnenten) übereinstimmt, müssen Sie die neue Abonnentendatenbank vollständig erstellen.

Alten Anbieter und altes Abo entfernen

Wenn Sie eine unidirektionale Replikation möchten, müssen Sie die alte Anbieter-/Abonnentenkonfiguration entfernen.

Entfernen Sie das alte Abo beim neuen Anbieter:

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

Entfernen Sie den Replikationssatz beim 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

Um einen Switchover ohne Ausfallzeit durchzuführen oder zu verhindern, dass 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 berücksichtigen, es sei denn, es sind strenge Kontrollen vorhanden, um zu verhindern, dass gleichzeitig auf beide Knoten geschrieben wird.

Sie können die Konfiguration der 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 wird übernommen.
first_update_wins: Die Version der Daten mit dem ältesten Zeitstempel wird übernommen.

Um die bidirektionale Replikation einzurichten, konfigurieren Sie den Anbieter und den Abonnenten so, 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.

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

Failover mit pglogical-Replikation

Ein Failover tritt auf, wenn die Anbieterdatenbank aus irgendeinem Grund nicht mehr verfügbar ist und Sie die Anwendung so umstellen müssen, dass sie die Abonnentendatenbank verwendet.

Damit keine doppelten Daten versehentlich auf die Failover-Abonnentendatenbank angewendet werden, müssen Sie das Abo deaktivieren. So wird verhindert, dass Änderungen von einem wiederhergestellten Anbieter versehentlich angewendet werden, wenn der Anbieter wieder verfügbar ist.

Beenden Sie den Abonnenten test_sub_1:

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');