Come posso risolvere i problemi di replica logica di un cluster di database di origine Aurora compatibile con PostgreSQL?

Risoluzione

Configura i parametri di replica

Prima di risolvere i problemi di replica logica, configura i seguenti parametri per il gruppo di parametri del cluster di database:

• Imposta il valore rds.logical_replication su 1 per attivare la replica logica sul cluster di database.
• Imposta max_replication_slots su un valore che includa un numero di slot sufficiente per il numero di sottoscrizioni previsto e per ulteriori processi di sincronizzazione delle tabelle.
• Imposta max_wal_senders su un valore che supporti la quota max_replication_slots e le repliche fisiche correnti.
• Imposta max_logical_replication_workers su un valore che supporti il numero di sottoscrizioni e il numero di ulteriori worker richiesti dal sistema di replica per la sincronizzazione delle tabelle.
• Imposta max_worker_processes su un valore che sia almeno uno in più rispetto al valore max_logical_replication_workers. Ad esempio, se max_logical_replication_workers è 25, imposta max_worker_processes su 26.
• Se la copia dei dati è lenta, aumenta il valore max_sync_workers_per_subscription per controllare il numero di worker di sincronizzazione che elaborano l'impostazione delle sottoscrizioni e le aggiunte di nuove tabelle.

Importante: per applicare le modifiche precedenti, devi riavviare il cluster di database Aurora compatibile con PostgreSQL.

Verifica la configurazione delle pubblicazioni e delle sottoscrizioni

Dopo aver configurato i parametri di replica logica, verifica di aver configurato correttamente le pubblicazioni e le sottoscrizioni. Assicurati che la pubblicazione includa tutte le tabelle previste, che i parametri di sottoscrizione siano corretti e che l'utente di replica abbia le autorizzazioni appropriate.

Connettiti al database di origine, quindi esegui questi comandi.

Per verificare la configurazione delle pubblicazioni, esegui questi comandi:

SELECT * FROM pg_publication;
SELECT * FROM pg_publication_tables;

Per verificare la configurazione delle sottoscrizioni, esegui questi comandi:

SELECT * FROM pg_subscription;
SELECT * FROM pg_subscription_rel;

Verificare che gli slot di replica siano attivi

Connettiti al database di origine, quindi esegui questo comando:

SELECT slot_name, plugin, slot_type, active, restart_lsn,
       confirmed_flush_lsn, pg_current_wal_lsn(),
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag
FROM pg_replication_slots;

Se gli slot sono inattivi o mostrano un ritardo eccessivo, esamina i worker di replica per risolvere il problema.

Verifica che i worker di replica siano attivi

Connettiti al database di destinazione, quindi esegui questo comando:

SELECT pid, state, query, wait_event, backend_type
FROM pg_stat_activity
WHERE backend_type LIKE 'logical replication%';

Se non sono presenti worker di replica, riavvia la sottoscrizione.

Per disattivare la sottoscrizione, esegui questo comando:

ALTER SUBSCRIPTION subscription_name DISABLE;

Per attivare la sottoscrizione, esegui questo comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Se non sono ancora presenti worker di replica dopo il riavvio della sottoscrizione, controlla i messaggi di errore nei log degli errori di PostgreSQL.

Monitora l'avanzamento e il ritardo di replica

La replica potrebbe subire un ritardo a causa di un volume elevato di transazioni e di transazioni di grandi dimensioni nella pubblicazione. Oppure potrebbero essere presenti vincoli nella pubblicazione o nella sottoscrizione.

Per stabilire se la replica è interrotta o lenta, monitora l'avanzamento della replica per alcuni intervalli.

Connettiti al cluster di database, quindi esegui questi comandi.

Per verificare l'avanzamento della replica per la pubblicazione, esegui questo comando:

SELECT slot_name,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag,
       active
FROM pg_replication_slots
WHERE slot_type = 'logical';

Per verificare lo stato di avanzamento della replica per la sottoscrizione, esegui questo comando:

SELECT subname, pid, received_lsn, latest_end_lsn,
       pg_size_pretty(pg_wal_lsn_diff(latest_end_lsn, received_lsn)) AS lag
FROM pg_stat_subscription;

Per ridurre al minimo il ritardo di replica, monitora la cache write-through. Se la dimensione della cache non è sufficiente per i carichi di lavoro, puoi modificare manualmente il valore rds.logical_wal_cache. Per ulteriori informazioni, consulta Achieve up to 17x lower replication lag with the new write-through cache for Aurora PostgreSQL (Come ridurre il ritardo di replica fino a 17 volte con la nuova cache write-through per Aurora PostgreSQL).

Monitora i vincoli delle risorse

Per risolvere i problemi relativi alle risorse per la pubblicazione e per la sottoscrizione, attiva Monitoraggio avanzato e monitora le metriche CPUUtilization, FreeableMemory, SwapUsage e NetworkThroughput. Configura in Amazon CloudWatch allarmi per ricevere notifiche quando si verificano problemi di replica.

Per ulteriori informazioni, consulta Come posso identificare e risolvere i problemi di prestazioni e di query a esecuzione lenta nella mia istanza database Amazon RDS per PostgreSQL o Aurora compatibile con PostgreSQL?

Identifica le discrepanze dello schema e risolvi le incongruenze dei dati

Connettiti al database di origine e al database di destinazione. Quindi verifica che siano presenti colonne nelle tabelle replicate e che i tipi di dati siano compatibili. Inoltre, assicurati che le chiavi primarie e i vincoli univoci siano coerenti.

Per attivare la sottoscrizione, esegui questo comando:

ALTER SUBSCRIPTION subscription_name ENABLE;

Per confrontare le definizioni delle tabelle, esegui questo comando su entrambi i database:

SELECT column_name, data_type, character_maximum_length
FROM information_schema.columns
WHERE table_name = 'your_table_name'
ORDER BY ordinal_position;

Nota: sostituisci your_table_name con il nome della tua tabella.

Risolvi i conflitti

La replica logica nativa di PostgreSQL non è in grado di rilevare conflitti di dati provenienti da più pubblicazioni o modifiche replicate in conflitto con dati modificati localmente. Se è presente una riga corrente con la stessa chiave, Aurora applica l'aggiornamento e l'inserimento non riesce.

Per identificare la causa del conflitto, controlla i log di PostgreSQL.

Il seguente esempio di log mostra che la replica non è riuscita perché ha tentato di inserire un record con un ID di risorsa già esistente nel database di destinazione:

ERROR: 23505: duplicate key value violates unique constraint "asset_pkey"
DETAIL: Key (asset_id)=(7) already exists.
CONTEXT: processing remote data for replication origin "pg_32796" during message type "INSERT" for replication target relation "public.asset" in transaction 315434, finished at 0/6A12458

L'origine della replica è pg_32796 e termina con il numero di sequenza logica (LSN) 0/6A12458.

Per correggere manualmente i dati, puoi interrompere la replica sul conflitto o configurare la sottoscrizione con l'opzione disable_on_error.

In alternativa, puoi esaminare i dati nell'origine e nella destinazione per stabilire se puoi ignorare l'LSN che ha causato il conflitto. Quindi utilizza la funzione pg_replication_origin_advance() per ignorare l'LSN che ha causato il conflitto. Per ulteriori informazioni, consulta pg_replication_origin_advance (node_name text, lsn pg_lsn) sul sito web PostgreSQL.

Nota: le versioni 15 e successive di Aurora compatibile con PostgreSQL supportano la funzione pg_replication_origin_advance().

Per ignorare l'LSN, completa i seguenti passaggi:

1. Esegui questo comando SQL per disattivare temporaneamente la sottoscrizione:

   ALTER SUBSCRIPTION subscription_name DISABLE;

   Nota: se hai configurato la sottoscrizione con l'opzione disable_on_error, la sottoscrizione si disattiva automaticamente dopo un errore.

2. Utilizza la seguente funzione pg_replication_origin_advance() per far avanzare l'origine a Finish_LSN+1:

   SELECT pg_replication_origin_advance('node_name','Finish_LSN+1'::pg_lsn);

   Nota: sostituisci node_name con il nome del tuo nodo.

3. Esegui questo comando per attivare la sottoscrizione:

   ALTER SUBSCRIPTION subscription-name ENABLE;

   Nota: sostituisci subscription-name con il nome della tua sottoscrizione.

Per risolvere diverse incongruenze nei dati, potresti dover pulire la tabella di destinazione e riconfigurare la pubblicazione e la sottoscrizione.

Informazioni correlate

Replica con Amazon Aurora PostgreSQL

PostgreSQL Logical Replication (Replica logica di PostgreSQL) sul sito web PostgreSQL

Configurazione della replica logica per il cluster di database Aurora PostgreSQL

Monitoraggio delle metriche di Amazon Aurora con Amazon CloudWatch