Come posso risolvere l'errore "canceling statement due to conflict with recovery" quando interrogo la replica in lettura per la mia istanza database Amazon RDS per PostgreSQL?

3 minuti di lettura
0

Ho configurato una replica in lettura per la mia istanza Amazon Relational Database Service (Amazon RDS) per PostgreSQL. Quando interrogo la replica in lettura, ricevo l'errore "canceling statement due to conflict with recovery".

Risoluzione

Se c'è un conflitto di replica tra l'istanza primaria e la replica in lettura, viene visualizzato l'errorecancelling statement. PostgreSQL non può applicare le informazioni WAL sulla replica in lettura perché le modifiche potrebbero bloccare un'attività in corso sulla replica in lettura. Ad esempio, si esegue un'istruzione DROP sull'istanza primaria quando un'istruzione SELECT è in esecuzione sulla tabella eliminata nella replica in lettura. Se la replica in lettura applica il record WAL e annulla l'istruzione SELECT, viene visualizzato l'errore cancelling statement.

Per risolvere l'errore cancelling statement, imposta parametri personalizzati sulla replica in lettura in base ai dettagli del messaggio di errore.

Puoi inoltre utilizzare la vista pg_stat_database_conflicts sulla replica in lettura per le statistiche sulle istruzioni annullate a causa di conflitti con il ripristino. Per ulteriori informazioni, consulta 27.2.18 pg_stat_database_conflicts sul sito web PostgreSQL.

Dettagli del messaggio di errore: "User was holding a relation lock for too long"

Per risolvere questo problema, modifica i parametri max_standby_streaming_delay o max_standby_archive_delay per attendere più tempo prima che la replica in lettura annulli un'istruzione di standby in conflitto. Se la replica in lettura legge i dati WAL dalla replica in streaming, modifica il parametro max_standby_streaming_delay. Se la replica in lettura legge i dati WAL dalla posizione di archivio in Amazon Simple Storage Service (Amazon S3), modifica il parametro max_standby_archive_delay.

Per ulteriori informazioni su questi parametri, consulta max_standby_streaming_delay (integer) e max_standby_archive_delay (integer) sul sito web PostgreSQL.

Se imposti il valore del parametro su 0, la replica in lettura annulla le query in conflitto e applica le voci WAL sull'istanza di replica. Se imposti il valore su -1, consenti all'istanza di replica di attendere per sempre le query in conflitto e il ritardo di replica aumenta. In base al caso d'uso, regola i valori di questi parametri per bilanciare l'annullamento delle query o il ritardo di replica.

Nota: se aumenti max_standby_archive_delay per mantenere le query in conflitto con la lettura delle voci dell'archivio WAL, è consigliabile aumentare anche max_standby_streaming_delay per evitare annullamenti.

Dettagli del messaggio di errore: "User query might have needed to see row versions that must be removed"

Questo problema si verifica in genere quando una transazione sulla replica in lettura sta leggendo tuple impostate per l'eliminazione sull'istanza primaria. Per risolvere il problema, potrebbe essere necessario attivare il parametro hot_standby_feedback.

Quando attivi hot_standby_feedback, la replica in lettura invia messaggi di feedback all'istanza primaria con informazioni sulla transazione attiva meno recente. Di conseguenza, l'istanza primaria non rimuove i record che potrebbero essere necessari per la transazione. Per ulteriori informazioni su questo parametro, consulta hot_standby_feedback (boolean) sul sito web PostgreSQL.

Importante: per impostazione predefinita il parametro hot_standby_feedback è disattivato. Quando attivi hot_standby_feedback sulla replica in lettura, le query di lunga durata sulla replica in lettura potrebbero causare un bloat della tabella sull'istanza primaria. Le operazioni vacuum non rimuovono le tuple inutilizzate (bloat) che potrebbero richiedere le query di lunga durata. Per ridurre il rischio di bloat, è consigliabile ridurre ancheautovacuum_threshold e autovacuum_vacuum_scale_factor e aumentareautovacuum_cost_limit.