Come posso risolvere il ritardo di replica della mia istanza database Amazon RDS per PostgreSQL?

Breve descrizione

Quando le repliche in lettura di RDS per PostgreSQL rimangono indietro rispetto all'istanza primaria, può verificarsi un ritardo nella replica.

La replica in lettura utilizza la replica in streaming nativa di PostgreSQL per mantenere la sincronizzazione. Il ricevitore del WAL (Write Ahead Log) nella replica in lettura richiede i dati WAL dall'istanza primaria. Quando il mittente del WAL nell'istanza primaria non riesce a trovare i dati del WAL richiesti, invia un errore all'istanza secondaria. Quindi RDS per PostgreSQL tenta di recuperare i dati del WAL archiviati da Amazon Simple Storage Service (Amazon S3). Se rimuovi il WAL dall'istanza primaria, la replica non può riprendere perché Amazon S3 non supporta il ripristino delle repliche multi-Regione.

Per ulteriori informazioni, consulta Utilizzo delle repliche in lettura per Amazon RDS per PostgreSQL.

Nota: la seguente risoluzione riguarda i problemi di replica in streaming. Per informazioni sulla replica logica, consulta Come posso utilizzare la replica logica per replicare le tabelle tra le mie istanze database Amazon RDS per PostgreSQL?

Risoluzione

Identifica i problemi di replica

Per identificare lo specifico problema di replica, esamina le seguenti metriche:

• ReplicaLag in Amazon CloudWatch: questa metrica misura il tempo in secondi corrispondente al ritardo della replica in lettura rispetto all'istanza database di origine.
• Stato di replica nella console Amazon Aurora e RDS: se la replica si interrompe, questo campo diventa Errore.
• oldestreplicationslotlag in PostgreSQL versione 14.1 e successive quando utilizzi slot di replica: questa metrica mostra la quantità di dati del WAL in byte che la replica con maggiore ritardo non ha ricevuto.

Puoi anche esaminare i parametri che controllano la replica di PostgreSQL.

Quando il ritardo di replica aumenta, potresti ricevere messaggi di evento simili ai seguenti:

"Streaming replication has stopped." Questo errore indica che la replica in streaming tra istanza primaria e di replica non è riuscita. La replica passa alla riproduzione dall'archivio in Amazon S3.

"Streaming replication has been terminated." Questo errore si verifica dopo 30 giorni consecutivi di interruzione della replica. Amazon RDS interrompe la replica per prevenire l'uso eccessivo dello spazio di archiviazione.

Nota: dopo l'interruzione della replica, l'istanza di replica in lettura è disponibile ma non puoi riprendere la replica. Per recuperare da questo stato, ricrea la replica in lettura.

Verifica eventuali discrepanze di configurazione

È consigliabile impostare le repliche in lettura in modo che corrispondano o superino le specifiche dell'istanza primaria. Una classe di istanza più piccola o un tipo di archiviazione diverso possono causare ritardi. La replica deve elaborare lo stesso carico di lavoro di scrittura dell'istanza primaria ed elaborare anche le query di lettura. Modifica l'istanza della replica in lettura, se necessario.

Esamina il carico di scrittura dell'istanza primaria e il carico di lettura della replica

Le operazioni di scrittura nell'istanza primaria creano molti file WAL. Per identificare la pressione di scrittura, monitora le seguenti metriche di CloudWatch e i valori di Monitoraggio avanzato:

• TransactionLogsDiskUsage
• TransactionLogsGeneration
• WriteIOPS
• WriteThroughput
• WriteLatency

Verifica la presenza di colli di bottiglia nel throughput per il tipo di classe dell'istanza database. Per evitare problemi, ripartisci le attività di scrittura in più transazioni. Puoi configurare allarmi in CloudWatch per WriteLatency e WriteIOPS in modo da identificare scritture pesanti nell'istanza di origine.

Un'elevata attività di lettura nelle repliche può rallentare la riproduzione di un file WAL. Per analizzare un carico di lavoro elevato e verificare la presenza di conflitti tra le risorse, utilizza le metriche di CloudWatch o Monitoraggio avanzato nell'istanza di replica. Se necessario, distribuisci il traffico di lettura su più repliche in lettura.

Monitora i blocchi delle tabelle

RDS per PostgreSQL elabora un blocco Access Exclusive quando esegui questi comandi sull'istanza primaria: DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL e REFRESH MATERIALIZED VIEW senza CONCURRENTLY. Per ulteriori informazioni, consulta Explicit locking (Blocco esplicito) sul sito web PostgreSQL.

Il blocco Access Exclusive impedisce l'accesso alla tabella da altre transazioni per la durata del blocco. La tabella rimane bloccata fino al termine della transazione. Il WAL registra l'attività di blocco e la replica in lettura riproduce e mantiene l'attività. Quanto maggiore è la durata del blocco Access Exclusive di una tabella, tanto maggiore è il ritardo di replica.

Per evitare il problema, è consigliabile eseguire periodicamente query sulle tabelle del catalogo pg_locks e pg_stat_activity.

Per monitorare i blocchi, esegui questo comando:

SELECT pid, usename, pg_blocking_pids(pid) AS blocked_by, QUERY AS blocked_query FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

L'output mostra le informazioni sulle query bloccate e sui relativi processi bloccati.

Controlla i parametri di replica di RDS per PostgreSQL

Per evitare problemi di replica, analizza i parametri che controllano la replica di RDS per PostgreSQL. Aggiorna i valori dei parametri, se necessario.

Per soddisfare il numero totale di connessioni di replica, puoi configurare max_replication_slots. Il valore predefinito varia in base alla classe di istanza. Questo valore deve essere uguale o superiore al numero totale di repliche.

I parametri max_standby_streaming_delay e max_standby_archive_delay nell'istanza di replica possono aiutare a completare le query di lettura lente. Se le query di lettura eseguite sulla replica modificano i dati di origine, questi parametri mettono in pausa la riproduzione del WAL. Se imposti il valore su -1, la riproduzione del WAL attende il completamento della query di lettura. Tuttavia, questa pausa può aumentare il ritardo di replica a tempo indeterminato e causare un elevato consumo di spazio di archiviazione nell'origine a causa dell'accumulo di WAL.

Per la stabilità della replica, RDS per PostgreSQL gestisce automaticamente diversi parametri: max_connections, max_worker_processes, max_wal_senders, max_prepared_transactions e max_locks_per_transaction. Nella replica, RDS per PostgreSQL imposta questi parametri in modo che corrispondano o superino i valori dell'istanza primaria.

Il parametro hot_standby_feedback consente alle repliche di segnalare i conflitti di query all'istanza primaria. Per impostazione predefinita, in RDS per PostgreSQL questo parametro è disattivato. Se lo attivi, le tabelle nell'istanza primaria potrebbero subire una proliferazione (bloat). Se ricevi il seguente messaggio di errore, utilizza il parametro hot_standby_feedback:

"ERROR: canceling statement due to conflict with recover. Detail: User query might have needed to see row versions that must be removed"

Consulta le best practice per la replica di RDS per PostgreSQL e le repliche in lettura multi-Regione

Potresti riscontrare un ritardo di replica anche per i seguenti motivi:

• Interruzioni di rete tra le istanze
• File WAL danneggiati o mancanti
• Operazioni di dimensionamento delle istanze
• Attività di manutenzione
• Periodi senza transazioni
  Nota: per ulteriori informazioni, consulta Utilizzo delle repliche in lettura per Amazon RDS per PostgreSQL.

Per informazioni su questi scenari, consulta Best practices for Amazon RDS PostgreSQL replication (Best practice per la replica di Amazon RDS PostgreSQL) e Best practices for Amazon RDS for PostgreSQL cross-Region read replicas (Best practice per le repliche in lettura multi-Regione di Amazon RDS for PostgreSQL).

Monitora le transazioni

Per controllare le transazioni attive nell'istanza primaria che potrebbero influire sulla replica, esegui questo comando:

SELECT datname, pid, usename, client_addr, backend_start, xact_start, current_timestamp - xact_start AS xact_runtime, state, backend_xmin FROM pg_stat_activity WHERE state='active' OR state='idle in transaction';

L'output mostra le transazioni attualmente in esecuzione e la loro durata. Le transazioni lente possono influire sulle prestazioni di replica.

Per interrompere una query problematica, esegui questo comando:

SELECT pg_terminate_backend(PID);

Nota: sostituisci PID con l'ID di processo della query che desideri interrompere.

Informazioni correlate

Replication (Replica) sul sito web PostgreSQL

Using logical replication to replicate managed Amazon RDS for PostgreSQL and Amazon Aurora to self-managed PostgreSQL (Utilizzo della replica logica per replicare Amazon RDS per PostgreSQL gestito e Amazon Aurora per PostgreSQL self-managed)