Como soluciono o erro “instrução de cancelamento devido ao conflito com a recuperação” quando consulto a réplica de leitura da minha instância de banco de dados do Amazon RDS para PostgreSQL?

Resolução

Se houver um conflito de replicação entre a instância primária e a réplica de leitura, você receberá o erro de instrução de cancelamento. O PostgreSQL não pode aplicar as informações do WAL na réplica de leitura porque as alterações podem bloquear uma atividade que está acontecendo na réplica de leitura. Por exemplo, você executa uma instrução DROP na instância primária quando uma instrução SELECT está sendo executada na tabela descartada na réplica de leitura. Se a réplica de leitura aplicar o registro WAL e cancelar a instrução SELECT, você receberá o erro de instrução de cancelamento.

Para resolver o erro de instrução de cancelamento, defina parâmetros personalizados na réplica de leitura com base nos detalhes da mensagem de erro.

Também é possível a visualização pg_stat_database_conflicts na réplica de leitura para obter estatísticas sobre declarações que são canceladas devido a conflitos com a recuperação. Para obter mais informações, consulte 27.2.18 pg_stat_database_conflicts no site do PostgreSQL.

Detalhes da mensagem de erro: “O usuário manteve um bloqueio de relacionamento por muito tempo”

Para resolver esse problema, altere os parâmetros max_standby_streaming_delay ou max_standby_archive_delay para permitir mais tempo antes que a réplica de leitura cancele uma instrução de espera conflitante. Se a réplica de leitura ler os dados WAL da replicação de streaming, modifique o parâmetro max_standby_streaming_delay. Se a réplica de leitura ler os dados WAL do local de arquivamento no Amazon Simple Storage Service (Amazon S3), modifique o parâmetro max_standby_archive_delay.

Para obter mais informações sobre esses parâmetros, consulte max_standby_streaming_delay (integer) e max_standby_archive_delay (integer) no site do PostgreSQL.

Se você definir o valor do parâmetro como 0, a réplica de leitura cancelará as consultas conflitantes e aplicará as entradas WAL na instância definir réplica. Se você definir o valor como -1, permitirá que a instância de réplica espere eternamente por consultas conflitantes e o atraso na replicação aumentará. Com base no seu caso de uso, ajuste os valores desses parâmetros para equilibrar o cancelamento da consulta ou o atraso na replicação.

Observação: Se você aumentar max_standby_archive_delay para manter consultas que entrem em conflito com a leitura de entradas do arquivo WAL, é uma prática recomendada também aumentar max_standby_streaming_delay para evitar cancelamentos.

Detalhes da mensagem de erro: “A consulta do usuário pode ter precisado ver as versões de linha que devem ser removidas”

Esse problema costuma ocorrer quando uma transação na réplica de leitura está lendo tuplas definidas para exclusão na instância primária. Para resolver esse problema, talvez seja necessário ativar o parâmetro hot_standby_feedback.

Quando você ativa hot_standby_feedback, a réplica de leitura envia mensagens de feedback para a instância primária com informações sobre a transação ativa mais antiga. Consequentemente, a instância primária não remove os registros que a transação possa precisar. Para obter mais informações sobre esse parâmetro, consulte hot_standby_feedback (boolean) no site do PostgreSQL.

Importante: O parâmetro hot_standby_feedback é desativado por padrão. Quando você ativa hot_standby_feedback na réplica de leitura, consultas de longa duração na réplica de leitura podem causar inchaço na tabela na instância primária. As operações de vácuo não removem as tuplas mortas (inchaço) que as consultas de longa duração podem exigir. Para reduzir o risco de inchaço, é uma prática recomendada também reduzir autovacuum_threshold e autovacuum_vacuum_scale_factor e aumentar autovacuum_cost_limit.