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

Questa pagina è stata tradotta dall'API Cloud Translation.

Switchover e failover con la replica pglogical

Seleziona una versione della documentazione:

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

Prima di iniziare

Una volta configurata la replica pglogical ed esistendo una soluzione di alta affidabilità (HA) e ripristino di emergenza (RE) valida, e riconoscendo che la replica logica non fornisce true e una replica 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 dei dati tra AlloyDB per PostgreSQL e AlloyDB Omni e Replica dei dati tra AlloyDB Omni e altri database.

Failover con la replica pglogical

Il cambio di ruolo è un processo controllato utilizzato per scambiare i ruoli tra i database del provider e del sottoscrittore. Quando esegui un cambio di ruolo, i ruoli dei due database, fornitore e abbonato, vengono invertiti. Il fornitore diventa l'abbonato e l'abbonato diventa il fornitore.

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

Per ottenere questo risultato nelle configurazioni di replica unidirezionale, devi configurare una nuova relazione fornitore/abbonato e rimuovere la vecchia relazione fornitore/abbonato.

Crea la nuova configurazione del fornitore/sottoscrittore

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

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 failover.

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 degli abbonati in un database del fornitore:
1. Interrompi l'abbonamento esistente.
2. Se necessario, aggiungi il set di replica.
3. Aggiungi le tabelle necessarie al set di repliche.
4. Crea un nuovo abbonamento per gli iscritti nel nuovo database degli iscritti.
5. Reindirizza le applicazioni al nuovo fornitore.
Interrompi l'abbonamento nel database degli abbonati esistente, che diventa il nuovo fornitore:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Facoltativo) Crea un set di replica che corrisponda alla definizione del database del fornitore 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 repliche.
- TABLE_NAME: Il nome della tabella di un proprietario dello schema. Ad esempio, ARRAY['public'].`

Nel nuovo database degli abbonati, che in precedenza era il database del fornitore, crea il nuovo abbonamento 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 l'abbonamento funziona sul nodo del fornitore:

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 che utilizzino il nuovo database del fornitore e riavvia i livelli dell'applicazione.

Se modifichi i dati sul nodo del vecchio fornitore 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 abbonato, non si trova in uno stato coerente con il nuovo database del provider, ovvero il vecchio abbonato, devi creare completamente il nuovo database dell'abbonato.

Rimuovere il vecchio fornitore e abbonamento

Se vuoi la replica unidirezionale, devi rimuovere la vecchia configurazione del fornitore/abbonato.

Rimuovi il vecchio abbonamento sul nuovo fornitore:

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

Rimuovi il set di repliche sul nuovo abbonato o rimuovi tutte le tabelle dal set di repliche:

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 configurare la risoluzione dei conflitti utilizzando le seguenti impostazioni pglogical.conflict_resolution:

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

Per configurare la replica bidirezionale, configura il fornitore e il sottoscrittore in modo che la replica avvenga in entrambe le direzioni. L'abbonato originale diventa anche un fornitore con lo stesso set di repliche del fornitore 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 duplichi il set di replica originale nel database del provider iniziale.

Sul fornitore originale, devi aggiungere un nuovo abbonato. Consulta Creare un nodo e una sottoscrizione nel database di sottoscrizione 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 della tabella dei dati.

Failover con replica pglogical

Il failover si verifica quando il database del fornitore non è più disponibile per qualsiasi motivo e devi passare all'applicazione per utilizzare il database del sottoscrittore.

Per evitare che i dati duplicati vengano applicati accidentalmente al database del sottoscrittore di cui è stato eseguito il failover, devi disattivare l'abbonamento. In questo modo, le modifiche apportate da un fornitore ripristinato non vengono applicate per errore quando il fornitore torna disponibile.

Interrompi l'abbonamento di 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');