Perché sono presenti ritardi ed errori di replica nell'istanza database RDS per PostgreSQL?

9 minuti di lettura
0

Ricevo errori di replica e ritardi nell'istanza del Servizio di database relazionale Amazon (Amazon RDS) per PostgreSQL.

Breve descrizione

Puoi dimensionare le letture per l'istanza database Amazon RDS per PostgreSQL aggiungendo repliche di lettura all'istanza. RDS per PostgreSQL utilizza la replica in streaming nativa di PostgreSQL per creare una copia di sola lettura di un'istanza database di origine. Questa istanza database di replica di lettura è una replica fisica dell'istanza database di origine creata in modo asincrono. Ciò significa che a volte la replica non riesce a tenere il passo con l'istanza database primaria. Di conseguenza, può verificarsi un ritardo di replica. Il DB di replica viene creato da una connessione speciale che trasmette i dati WAL (Write Ahead Log) dall'istanza database di origine alla replica di lettura. Pertanto, la replica di lettura controlla i registri WAL per replicare le modifiche apportate sull'istanza primaria. Quando la replica di lettura non riesce a trovare i dati WAL sull'istanza primaria, la replica di lettura viene recuperata dai dati WAL archiviati in Amazon Simple Storage Service (Amazon S3). Per ulteriori informazioni, vedi Funzionamento della replica in streaming per diverse versioni di RDS per PostgreSQL.

È possibile monitorare il ritardo di replica in Amazon CloudWatch visualizzando la metrica ReplicaLag di Amazon RDS. Questa metrica mostra fino a che punto una replica di lettura è rimasta indietro rispetto all'istanza database di origine. Amazon RDS monitora lo stato di replica della replica di lettura. Quindi, aggiorna il campo Replication State (Stato di replica) nella console Amazon RDS in Error (Errore) se la replica si interrompe per qualsiasi motivo. La metrica ReplicaLag indica la capacità di una replica di lettura di tenere il passo con l'istanza database di origine e la quantità di latenza tra quest'ultima e un'istanza di lettura specifica.

Risoluzione

È possibile che venga visualizzato uno dei seguenti errori nei registri degli errori di RDS per PostgreSQL quando il ritardo di replica aumenta:

  • La replica in streaming è stata interrotta: si verifica questo errore quando la replica in streaming tra le istanze primaria e di replica si interrompe. In questo caso, la replica inizia a essere riprodotta dal percorso di archivio in Amazon S3, determinando un ulteriore aumento del ritardo di replica.
  • La replica in streaming è stata terminata: si verifica questo errore quando la replica viene interrotta per più di 30 giorni consecutivi, manualmente o a causa di un errore di replica. In questo caso, Amazon RDS interrompe la replica tra l'istanza database primaria e tutte le repliche di lettura per evitare un aumento dei requisiti di archiviazione sull'istanza primaria e tempi di failover più lunghi.

L'istanza della replica di lettura è disponibile anche dopo il termine della replica. Tuttavia, la replica non può essere ripresa perché i registri delle transazioni richiesti dalla replica di lettura vengono eliminati dall'istanza primaria dopo il termine della replica.

I motivi più comuni per l'aumento del ritardo di replica sono i seguenti:

  • Differenze di configurazione tra le istanze primarie e di replica
  • Carico di lavoro di scrittura elevato sull'istanza primaria
  • Transazioni in esecuzione per un lungo periodo di tempo
  • Blocco esclusivo sulle tabelle delle istanze primarie
  • File WAL danneggiato o mancante
  • Problemi di rete
  • Impostazione errata dei parametri
  • Nessuna transazione

Differenze di configurazione tra istanza primaria e replica di lettura

Configurazioni errate dell'istanza di replica possono influire sulle prestazioni di replica. La replica di lettura gestisce un carico di lavoro di scrittura simile a quello dell'istanza di origine insieme a query di lettura aggiuntive. Pertanto, utilizza repliche della stessa classe di istanza o superiore e del tipo di archiviazione dell'istanza di origine. Poiché la replica deve riprodurre la stessa attività di scrittura dell'istanza di origine, l'utilizzo di una replica di classe di istanza inferiore può causare un'elevata latenza per la replica e aumentare il ritardo di replica. Anche le configurazioni di archiviazione non corrispondenti aumentano il ritardo di replica.

Carico di lavoro di scrittura elevato sull'istanza primaria

Un carico di lavoro di scrittura elevato sull'istanza primaria potrebbe creare un afflusso elevato di file WAL. Un aumento del numero di file WAL e la riproduzione di questi file nelle repliche di lettura potrebbero rallentare le prestazioni complessive di replica. Pertanto, quando si verifica un aumento del ritardo di replica, assicurati di controllare l'attività di scrittura sull'istanza primaria. È possibile utilizzare le metriche di CloudWatch o il monitoraggio avanzato per analizzare il carico di lavoro. Visualizza i valori per TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput e WriteLatency per scoprire se l'istanza di origine è sottoposta a carichi di lavoro di scrittura elevati. È inoltre possibile verificare la presenza di colli di bottiglia a livello di velocità di trasmissione effettiva. Ogni tipo di istanza ha la propria velocità di trasmissione effettiva dedicata. Per ulteriori informazioni, consulta Specifiche hardware per le classi di istanze database.

Per evitare questo problema, controlla e distribuisci l'attività di scrittura per l'istanza di origine. Invece di eseguire molte attività di scrittura insieme, suddividi le attività in pacchetti di attività più piccoli e poi distribuisci questi pacchetti in modo uniforme su più transazioni. È possibile utilizzare gli avvisi di CloudWatch per metriche, ad esempio Writelatency e WriteIOPS, per ricevere notifiche di scritture pesanti sull'istanza di origine.

Transazioni in esecuzione per un lungo periodo di tempo

Le transazioni attive che sono in esecuzione per un lungo periodo nel database potrebbero interferire con il processo di replica WAL, aumentando così il ritardo di replica. Pertanto, assicurati di monitorare il runtime delle transazioni attive con la vista pg_stat_activity di PostgreSQL.

Esegui una query sull’instanza primaria simile alla seguente per trovare l'ID processo (PID) della query in esecuzione per un lungo periodo di tempo:

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

Dopo aver identificato il PID della query, è possibile scegliere di terminare la query.

Esegui una query sull'istanza primaria simile alla seguente per terminare la query:

SELECT pg_terminate_backend(PID);

È inoltre possibile scegliere di riscrivere od ottimizzare la query per evitare transazioni in esecuzione per un lungo periodo di tempo.

Blocco esclusivo sulle tabelle delle istanze primarie

Quando si eseguono comandi sull'istanza primaria, ad esempio DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW (senza CONCURRENTLY), PostgreSQL elabora un blocco Access Exclusive. Questo blocco impedisce a tutte le altre transazioni di accedere alla tabella per la durata del blocco. Di solito, la tabella rimane bloccata fino al termine della transazione. Questa attività di blocco viene registrata in WAL e viene quindi riprodotta e mantenuta dalla replica di lettura. Più a lungo la tabella rimane sotto un blocco Access Exclusive, maggiore sarà il ritardo di replica.

Per evitare questo problema, è consigliabile monitorare le transazioni eseguendo periodicamente query sulle tabelle del catalogo pg_locks e pg_stat_activity.

Esempio:

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

File WAL danneggiato o mancante

Un file WAL danneggiato o mancante può causare un ritardo di replica. In questo caso, viene visualizzato un errore nei registri di PostgreSQL che indica che il WAL non può essere aperto. Potresti anche visualizzare l'errore "Il segmento WAL XXX richiesto è già stato rimosso".

Problemi di rete

Un'interruzione di rete tra le istanze primarie e di replica potrebbe causare problemi con la replica in streaming e conseguente aumento del ritardo di replica.

Impostazione errata dei parametri

L'impostazione errata di alcuni parametri personalizzati nel gruppo di parametri di configurazione del server potrebbe causare un aumento del ritardo di replica. Di seguito sono riportati alcuni dei parametri che è necessario impostare correttamente:

  • wal_keep_segments: questo parametro specifica il numero di file WAL che l'istanza primaria mantiene nella directory pg_wal. Il valore predefinito per questo parametro è impostato su 32. Se questo parametro non è impostato su un valore sufficientemente alto per la distribuzione, la replica di lettura potrebbe rimanere indietro, causando l'arresto della replica in streaming. In questo caso, RDS genera un errore di replica e avvia il ripristino sulla replica di lettura riproducendo i dati WAL archiviati dell'istanza primaria da Amazon S3. Questo processo di ripristino continua fino a quando la replica di lettura può continuare la replica in streaming.
    Nota: in PostgreSQL versione 13, il parametro wal_keep_segments è denominato wal_keep_size. Questo parametro ha lo stesso scopo di wal_keep_segments. Tuttavia, il valore predefinito per questo parametro è definito in MB (2048 MB) anziché in base al numero di file.
  • max_wal_senders: questo parametro specifica il numero massimo di connessioni che l'istanza primaria può supportare contemporaneamente tramite il protocollo di replica in streaming. Per RDS per PostgreSQL 13 e versioni successive, il valore predefinito per questo parametro è 20. Il parametro deve essere impostato su un valore leggermente superiore al numero effettivo di repliche di lettura. Se invece è impostato su un valore inferiore al numero di repliche di lettura, la replica si interrompe.
  • hot_standby_feedback: questo parametro specifica se l'istanza di replica invia un feedback all'istanza primaria sulle query attualmente in esecuzione nell'istanza di replica. Attivando questo parametro, si cura il seguente messaggio di errore nell'istanza di origine e si posticipa l'operazione VACUUM sulle tabelle correlate, a meno che la query di lettura nell'istanza di replica non sia completata. Pertanto, un'istanza di replica con hot_standby_feedback attivato può servire query a esecuzione prolungata. Tuttavia, questo parametro può sovraccaricare le tabelle nell'istanza di origine. Assicurati di monitorare le query a esecuzione prolungata nelle istanze di replica per evitare problemi seri come l'esaurimento dello spazio di archiviazione e il wrapping dell'ID transazione nell'istanza primaria.
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed
  • max_standby_streaming_delay/max_standby_archive_delay: è possibile abilitare parametri come max_standby_archive_delay o max_standby_streaming_delay sull'istanza di replica per completare query di lettura a esecuzione prolungata. Questi parametri mettono in pausa la riproduzione WAL nella replica se i dati di origine vengono modificati quando le query di lettura sono in esecuzione sulla replica. Il valore -1 per questi parametri mette in pausa la riproduzione WAL fino al completamento della query di lettura. Tuttavia, questa pausa aumenta il ritardo di replica a tempo indeterminato e causa un elevato consumo di archiviazione all'origine a causa dell'accumulo di dati WAL.

Nessuna transazione

Se non si verificano transazioni utente sull'istanza database di origine, la replica di lettura di PostgreSQL riporta un ritardo di replica fino a cinque minuti.


Informazioni correlate

Utilizzo delle repliche di lettura per Amazon RDS per PostgreSQL

Documentazione PostgreSQL per la configurazione del server

AWS UFFICIALE
AWS UFFICIALEAggiornata 2 anni fa