Como resolvo o atraso de replicação na minha instância de banco de dados do Amazon RDS para PostgreSQL?

Breve descrição

Quando as réplicas de leitura do RDS para PostgreSQL ficam atrás da instância primária, pode ocorrer um atraso na replicação.

A réplica de leitura usa a replicação de streaming nativa do PostgreSQL para manter a sincronização. O receptor Write Ahead Log (WAL) na réplica de leitura solicita os dados de WAL da instância primária. Quando o remetente do WAL na instância primária não consegue encontrar os dados de WAL solicitados, ele envia um erro para a instância secundária. Em seguida, o RDS para PostgreSQL tenta recuperar dados de WAL arquivados do Amazon Simple Storage Service (Amazon S3). Se você remover o WAL da instância primária, não será possível retomar a replicação porque o Amazon S3 não oferece suporte à recuperação de réplicas entre regiões.

Para obter mais informações, consulte Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL.

Observação: a resolução a seguir é para problemas de replicação de streaming. Para obter mais informações sobre replicação lógica, consulte Como uso replicação lógica para replicar tabelas entre minhas instâncias de banco de dados Amazon RDS para PostgreSQL?

Resolução

Identificar problemas de replicação

Para identificar seu problema específico de replicação, consulte as seguintes métricas:

• ReplicaLag no Amazon CloudWatch: essa métrica mede o tempo em segundos em que uma réplica de leitura fica atrás da instância de banco de dados de origem.
• Estado de replicação no console do Amazon Aurora e RDS: se a replicação for interrompida, esse campo será alterado para Erro.
• oldestreplicationslotlag no PostgreSQL versão 14.1 e posterior quando você usa slots de replicação: essa métrica mostra a quantidade de dados de WAL em bytes que a réplica mais atrasada não recebeu.

Também é possível consultar os parâmetros que controlam a replicação do PostgreSQL.

Quando o atraso na replicação aumenta, é possível receber mensagens de eventos semelhantes às seguintes:

"Streaming replication has stopped." Esse erro significa que a replicação de streaming entre as instâncias primária e de réplica falhou. As opções de replicação são reproduzidas a partir do arquivamento no Amazon S3.

"Streaming replication has been terminated." Esse erro ocorre após 30 dias consecutivos de interrupção da replicação. O Amazon RDS encerra a replicação para evitar o uso excessivo do armazenamento.

Observação: depois que a replicação for interrompida, a instância de réplica de leitura estará disponível, mas não será possível retomar a replicação. Para se recuperar desse estado, recrie a réplica de leitura.

Verificar se há incompatibilidades de configuração

É uma prática recomendada configurar suas réplicas de leitura para que correspondam ou excedam as especificações da instância primária. Uma classe de instância menor ou um tipo de armazenamento diferente podem causar atraso. A réplica deve processar o mesmo workload de gravação da primária e também processar consultas de leitura. Modifique sua instância de réplica de leitura, se necessário.

Consultar a carga de gravação da instância primária e a carga de leitura da réplica

As operações de gravação na instância primária criam vários arquivos WAL. Para identificar a pressão de gravação, monitore as seguintes métricas do CloudWatch e os valores do Monitoramento aprimorado:

• TransactionLogsDiskUsage
• TransactionLogsGeneration
• WriteIOPS
• WriteThroughput
• WriteLatency

Verifique se há gargalos de throughput para seu tipo de classe de instância de banco de dados. Para evitar problemas, distribua atividades de gravação em várias transações. É possível configurar os alarmes do CloudWatch para WriteLatency e WriteIOPS para identificar gravações pesadas na instância de origem.

A alta atividade de leitura em réplicas pode retardar a reprodução de arquivos WAL. Para analisar o alto workload e verificar a contenção de recursos, use as métricas do CloudWatch ou o Monitoramento aprimorado na instância de réplica. Se necessário, distribua o tráfego de leitura em várias réplicas de leitura.

Monitorar bloqueios de tabela

O RDS para PostgreSQL processa um bloqueio do Access Exclusive quando você executa estes comandos na instância primária: DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL e REFRESH MATERIALIZED VIEW sem CONCURRENTLY. Para mais informações, consulte Explicit locking (Bloqueio explícito) no site do PostgreSQL.

O bloqueio do Access Exclusive impede o acesso à tabela a partir de outras transações durante o período de espera do bloqueio. A tabela permanece bloqueada até que a transação termine. O WAL registra a atividade de bloqueio e a réplica de leitura reproduz e mantém a atividade. Quanto mais tempo a tabela permanecer sob um bloqueio do Access Exclusive, maior será o atraso na replicação.

Para evitar esse problema, é uma prática recomendada consultar periodicamente as tabelas do catálogo pg_locks e pg_stat_activity.

Para monitorar bloqueios, execute o seguinte 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;

A saída mostra informações sobre consultas bloqueadas e seus processos bloqueados.

Verificar os parâmetros de replicação do RDS para PostgreSQL

Para evitar problemas de replicação, consulte os parâmetros que controlam a replicação do RDS para PostgreSQL. Atualize os valores dos parâmetros, se necessário.

Para acomodar o número total de conexões de replicação, é possível configurar max_replication_slots. O valor padrão varia de acordo com a classe da instância. Esse valor deve ser igual ou superior ao número total de réplicas.

Os parâmetros max_standby_streaming_delay e max_standby_archive_delay na instância de réplica podem ajudar a concluir consultas de leitura de longa duração. Se as consultas de leitura executadas na réplica modificarem os dados de origem, esses parâmetros pausarão a reprodução do WAL. Se você definir o valor como -1, a reprodução do WAL aguardará até que a consulta de leitura seja concluída. No entanto, essa pausa pode aumentar o atraso de replicação indefinidamente e causar alto consumo de armazenamento na origem devido ao acúmulo de WAL.

Para estabilidade de replicação, o RDS para PostgreSQL gerencia automaticamente vários parâmetros: max_connections, max_worker_processes, max_wal_senders, max_prepared_transactions e max_locks_per_transaction. Na sua réplica, o RDS para PostgreSQL define esses parâmetros para corresponder ou exceder os valores da instância primária.

O parâmetro hot_standby_feedback permite que as réplicas registrem conflitos de consulta à instância primária. O RDS para PostgreSQL desativa esse parâmetro por padrão. Se você ativar o parâmetro, as tabelas na instância primária poderão aumentar. Se você receber a seguinte mensagem de erro, use o parâmetro 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"

Analisar as práticas recomendadas de replicação do RDS para PostgreSQL e réplicas de leitura entre regiões

Também é possível enfrentar um atraso na replicação pelos seguintes motivos:

• Interrupções de rede entre instâncias
• Arquivos WAL corrompidos ou ausentes
• Operações de escalabilidade de instâncias
• Atividades de manutenção
• Períodos sem transações
  Observação: para obter mais informações, consulte Trabalhar com réplicas de leitura do Amazon RDS para PostgreSQL.

Para obter mais informações sobre esses casos, consulte Best practices for Amazon RDS PostgreSQL replication (Práticas recomendadas de replicação do Amazon RDS para PostgreSQL) e Best practices for Amazon RDS for PostgreSQL cross-Region read replicas (Práticas recomendadas de réplicas de leitura entre regiões do Amazon RDS para PostgreSQL).

Monitorar transações

Para verificar as transações ativas na instância primária que podem afetar a replicação, execute o seguinte 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';

A saída mostra as transações atualmente em execução e a duração delas. Transações de longa duração podem afetar o desempenho da replicação.

Para interromper uma consulta problemática, execute o seguinte comando:

SELECT pg_terminate_backend(PID);

Observação: substitua PID pelo número de ID do processo da consulta que você deseja interromper.

Informações relacionadas

Replication (Replicação) no site do PostgreSQL

Using logical replication to replicate managed Amazon RDS for PostgreSQL and Amazon Aurora to self-managed PostgreSQL (Uso da replicação lógica para replicar o Amazon RDS para PostgreSQL gerenciado e o Amazon Aurora para o PostgreSQL autogerenciado)