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

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Switchover und Failover mit der pglogical-Replikation

Wählen Sie eine Dokumentenversion aus:

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

Hinweis

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

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

Der Wechsel ist ein kontrollierter Prozess, mit dem die Rollen zwischen der Anbieter- und der Abonnentendatenbank 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 Switchover-Funktion ist wichtig für Betriebssystemupgrades, PostgreSQL-Upgrades oder Failover-Tests.

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

Neue Anbieter-/Abonnentenkonfiguration erstellen

Beenden Sie die Schreibvorgänge der Anwendung in das Anbietersystem, 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 alle Verzögerungsfelder null anzeigen, ist die Replikation auf dem neuesten Stand und die Datenbank ist für das 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

Konvertieren Sie die Abonnentendatenbank in eine Anbieterdatenbank:
1. Beenden Sie das bestehende Abo des Abonnenten.
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 für die vorhandene 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 Standard-Replikationssätze verwenden:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Fügen Sie diesem Replikations-Dataset 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, die auf false festgelegt ist, 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, die der alte Abonnent ist, konsistent ist, 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 Anbieter-/Abonnentenkonfiguration entfernen.

Entfernen Sie das alte Abo beim neuen Anbieter:

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 Ausfallzeiten umstellen oder sicherstellen möchten, dass aufgrund ungeplanter Datenänderungen keine Daten 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 gleichzeitigen Schreibzugriff auf beide Knoten verhindern.

Sie können die Konfiguration für die Konfliktauflö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 der Änderungskonflikt wird verworfen.
last_update_wins: Die Version der Daten mit dem neuesten Commit-Zeitstempel sind die Daten, die per Commit übertragen werden.
first_update_wins: Die Version der Daten mit dem ältesten Zeitstempel wird übernommen.

Wenn Sie eine bidirektionale Replikation einrichten möchten, konfigurieren Sie den Anbieter und den Abonnenten so, dass die Replikation in beide Richtungen erfolgt. Der ursprüngliche Abonnent wird ebenfalls 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 erfahren Sie, wie Sie einen Replikationssatz erstellen, 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 die erste Tabellenkopie der 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 auf die Abonnentendatenbank umstellen müssen.

Damit keine doppelten Daten versehentlich auf die Abonnentendatenbank angewendet werden, für die ein Failover durchgeführt wurde, 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');