Auf dieser Seite finden Sie die Dokumentation für AlloyDB Omni Version 15.7.0.
Unter Dokumentationsversionen für AlloyDB Omni können Sie eine andere Version auswählen.

Diese Seite wurde von der Cloud Translation API übersetzt.

Switchover und Failover mit der pglogical-Replikation

Auf dieser Seite finden Sie Informationen zum Umschalten und Failover bei der pglogical-Replikation.

Hinweise

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

Weitere Informationen zur pglogical-Erweiterung finden Sie unter pglogical.

Informationen zur Datenreplizierung mit pglogical finden Sie unter Daten zwischen Google Cloud AlloyDB und AlloyDB Omni replizieren und Daten zwischen AlloyDB Omni und anderen Datenbanken replizieren.

Umstellung mit pglogical-Replikation

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

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

Dazu müssen Sie in unidirektionalen Replikationskonfigurationen eine neue Anbieter-/Abonnentenbeziehung einrichten und die alte Anbieter-/Abonnentenbeziehung entfernen.

Neue Anbieter-/Abonnentenkonfiguration erstellen

Verhindern Sie, dass die Anwendung Daten in das Anbietersystem schreibt, um weitere Datenbankänderungen zu verhindern. Prüfen Sie außerdem 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 „0“ angezeigt wird, ist die Replikation auf dem neuesten Stand und die Datenbank ist für ein Switchover bereit.

Die Ausgabe sieht in 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

Konvertieren Sie die Abonnentendatenbank in eine Anbieterdatenbank:
1. Beenden Sie das bestehende Abo.
2. Fügen Sie bei Bedarf das Replikations-Set hinzu.
3. Fügen Sie dem Replikations-Dataset die erforderlichen Tabellen hinzu.
4. Erstelle ein neues Abo 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 ein Replikations-Set, das der Definition der ursprünglichen Anbieterdatenbank entspricht. Dies ist nicht erforderlich, wenn Sie die standardmäßigen Replikationssä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 Schemainhabers. Beispiel: ARRAY['public'].`

Erstelle in der neuen Abonnentendatenbank, die zuvor die Anbieterdatenbank war, das neue Abo mit der Option synchronize_data auf false, um das erstmalige 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 Anwendungsverbindungsstrings so, dass die neue Anbieterdatenbank verwendet wird, 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. Dies führt zu Datenverlusten. Wenn es nicht replizierte Datenänderungen in der ursprünglichen Anbieterdatenbank gibt oder der ursprüngliche Anbieter (der neue Abonnent) sich nicht in einem Zustand befindet, der mit der neuen Anbieterdatenbank (dem alten Abonnenten) übereinstimmt, müssen Sie die neue Abonnentendatenbank vollständig neu erstellen.

Alten Anbieter und Abo entfernen

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

Entfernen Sie das alte Abo beim neuen Anbieter:

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

Entfernen Sie das Replikations-Set vom neuen Abonnenten oder entfernen Sie alle Tabellen aus dem Replikations-Set:

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 dafür sorgen möchten, dass keine Daten aufgrund unvorhergesehener 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 gibt strenge Kontrollen, die den Schreibzugriff auf beide Knoten gleichzeitig verhindern.

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

error: Der Abonnent stoppt, wenn ein Konflikt erkannt wird.
apply_remote: Die eingehenden Änderungen werden immer unabhängig von den Daten in der Abonnentendatenbank angewendet. Dies ist die Standardeinstellung.
keep_local: Die in Konflikt stehenden eingehenden Daten werden immer ignoriert und die in Konflikt stehende Änderung 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 verbindlich ist.

Wenn Sie eine bidirektionale Replikation einrichten möchten, richten Sie den Anbieter und den Abonnenten so ein, dass die Replikation in beide Richtungen erfolgt. Der ursprüngliche Abonnent wird ebenfalls zu einem Anbieter mit demselben Replikationssatz wie der ursprüngliche Anbieter. Weitere Informationen zum Erstellen eines Replikationssatzes, der den ursprünglichen Replikationssatz in der ursprünglichen Anbieterdatenbank dupliziert, finden Sie unter Tabelle erstellen und dem Standardreplizierungssatz in der Google Cloud AlloyDB-Anbieterdatenbank hinzufügen.

Sie müssen beim ursprünglichen Anbieter einen neuen Abonnenten hinzufügen. Weitere Informationen zum Erstellen eines neuen Abonnenten findest du unter Knoten und Abo in der AlloyDB Omni-Abonnentendatenbank erstellen. Achte dabei darauf, dass der Parameter synchronize_data für den Befehl pglogical.create_subscription auf false gesetzt ist. So wird die anfängliche Tabellenkopie der Daten vermieden.

Failover mit pglogical-Replikation

Ein Failover tritt auf, wenn die Anbieterdatenbank aus irgendeinem Grund nicht mehr verfügbar ist und du die Anwendung auf die Abonnentendatenbank umstellen musst.

Damit nicht versehentlich doppelte Daten auf die Datenbank mit den fehlgeschlagenen Abonnenten angewendet werden, musst du das Abo deaktivieren. So wird verhindert, dass Änderungen von einem wiederhergestellten Anbieter versehentlich angewendet werden, wenn der Anbieter wieder verfügbar ist.

So beendest du die Übertragung an 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');