Questa pagina documenta la versione 15.7.1 di AlloyDB Omni utilizzando l'opzione di deployment container. Scegli un'altra opzione di implementazione.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Switchover e failover con la replica pglogical

Seleziona una versione della documentazione:

Questa pagina fornisce informazioni su come eseguire il failover e il failback con la replica pglogical.

Prima di iniziare

Dopo aver configurato la replica di pglogical e aver ottenuto una soluzione di alta affidabilità (HA) e ripristino di emergenza (RE) valida, e riconoscendo che la replica logica non fornisce una replica true e completa di tutti gli oggetti del database, devi testare questa configurazione prima di iniziare a utilizzarla.

Per saperne di più sull'estensione pglogical, consulta Informazioni su pglogical.

Per informazioni sulla replica dei dati utilizzando pglogical, consulta Replica i dati tra AlloyDB per PostgreSQL e AlloyDB Omni e Replica i dati tra AlloyDB Omni e altri database.

Switchover con replica pglogical

Il cambio è un processo controllato utilizzato per scambiare i ruoli tra i database provider e subscriber. Quando esegui uno switchover, i ruoli dei due database, provider e subscriber, vengono invertiti. Il provider diventa il sottoscrittore e il sottoscrittore diventa il provider.

Questa funzionalità di switchover è importante per gli upgrade del sistema operativo, gli upgrade di PostgreSQL o i test di failover.

Per farlo nelle configurazioni di replica unidirezionale, devi configurare una nuova relazione provider/subscriber e rimuovere quella precedente.

Crea la nuova configurazione provider/sottoscrittore

Interrompi la scrittura dell'applicazione nel sistema provider per impedire ulteriori modifiche al database e controlla il ritardo di replica per assicurarti che tutte le transazioni vengano riprodotte sul nodo subscriber:

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;

Quando tutti i campi di ritardo mostrano zero, la replica è aggiornata e il database è pronto per un passaggio.

L'output è simile al seguente:

-[ 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

Converti il database del sottoscrittore in un database del provider:
1. Interrompi l'abbonamento dell'abbonato esistente.
2. Se necessario, aggiungi il set di replica.
3. Aggiungi le tabelle necessarie al set di replica.
4. Crea un nuovo abbonamento per l'abbonato nel nuovo database degli abbonati.
5. Reindirizza le applicazioni al nuovo provider.
Interrompi la sottoscrizione nel database del sottoscrittore esistente, che diventa il nuovo provider:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Facoltativo) Crea un set di replica che corrisponda alla definizione del database del provider originale. Questo passaggio non è necessario se utilizzi i set di replica predefiniti:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Aggiungi tabelle al set di replica:
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
Sostituisci quanto segue:
- REPLICATION_SET_NAME: il nome del set di replica.
- TABLE_NAME: il nome della tabella di un proprietario dello schema. Ad esempio: ARRAY['public'].`

Nel nuovo database del sottoscrittore, che in precedenza era il database del provider, crea la nuova sottoscrizione con l'opzione synchronize_data impostata su false per impedire il caricamento iniziale della tabella:

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

Controlla se la sottoscrizione funziona sul nodo provider:

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;

Se la replica funziona, modifica le stringhe di connessione dell'applicazione in modo da utilizzare il nuovo database del provider e riavvia i livelli dell'applicazione.

Se modifichi i dati sul nodo provider precedente dopo l'arresto del sottoscrittore, queste modifiche non vengono replicate e si verifica una perdita di dati. Se sono presenti modifiche ai dati non replicate nel database del provider originale o se il provider originale, ovvero il nuovo subscriber, non è in uno stato coerente con il database del nuovo provider, ovvero il vecchio subscriber, devi creare completamente il nuovo database del subscriber.

Rimuovi il vecchio fornitore e l'abbonamento

Se vuoi una replica unidirezionale, devi rimuovere la vecchia configurazione provider/subscriber.

Rimuovi la vecchia sottoscrizione presso il nuovo provider:

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

Rimuovi il set di replica sul nuovo sottoscrittore o rimuovi tutte le tabelle dal set di replica:

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

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

Replica bidirezionale

Per eseguire il passaggio senza tempi di inattività o per assicurarti che non vengano persi dati a causa di modifiche non pianificate, devi utilizzare la replica bidirezionale. Quando implementi la replica bidirezionale, considera la risoluzione dei conflitti, a meno che non siano in atto controlli rigorosi per impedire l'accesso in scrittura a entrambi i nodi contemporaneamente.

Puoi impostare la configurazione della risoluzione dei conflitti utilizzando le seguenti impostazioni pglogical.conflict_resolution:

error: il sottoscrittore si interrompe quando viene rilevato un conflitto.
apply_remote: applica sempre le modifiche in entrata indipendentemente dai dati nel database del sottoscrittore. Questa è l'impostazione predefinita.
keep_local: ignora sempre i dati in entrata in conflitto e scarta la modifica in conflitto.
last_update_wins: la versione dei dati con il timestamp di commit più recente è quella di cui viene eseguito il commit
first_update_wins: viene eseguito il commit della versione dei dati con il timestamp più vecchio

Per configurare la replica bidirezionale, configura il publisher e il sottoscrittore in modo che la replica avvenga in entrambe le direzioni. Il sottoscrittore originale diventa anche un provider con lo stesso set di replica del provider originale. Consulta Crea una tabella e aggiungila al set di replica predefinito nel database del provider AlloyDB per PostgreSQL per creare un set di replica che duplica il set di replica originale nel database del provider iniziale.

Sul provider originale, devi aggiungere un nuovo abbonato. Consulta Crea un nodo e una sottoscrizione nel database del sottoscrittore AlloyDB Omni per creare un nuovo sottoscrittore assicurandoti che il parametro synchronize_data per il comando pglogical.create_subscription sia impostato su false. In questo modo si evita la copia iniziale dei dati della tabella.

Failover con replica pglogical

Il failover si verifica quando il database del provider non è disponibile per qualsiasi motivo e devi cambiare l'applicazione per utilizzare il database del sottoscrittore.

Per evitare che dati duplicati vengano applicati accidentalmente al database del sottoscrittore sottoposto a failover, devi disattivare la sottoscrizione. In questo modo, le modifiche di un provider ripristinato non vengono applicate per errore quando il provider torna disponibile.

Interrompi il sottoscrittore, test_sub_1:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Verifica che lo stato sia impostato su disabled:

SELECT pglogical.show_subscription_status('test_sub_1');