Por que tenho atrasos e erros de replicação na minha instância de banco de dados do RDS para PostgreSQL?

10 minuto de leitura
0

Estou recebendo erros e atrasos de replicação na minha instância do Amazon Relational Database Service (Amazon RDS) para PostgreSQL.

Breve descrição

Você pode escalar leituras para sua instância de banco de dados do Amazon RDS para PostgreSQL adicionando réplicas de leitura à instância. O RDS para PostgreSQL usa a replicação de streaming nativa do PostgreSQL para criar uma cópia somente leitura de uma instância de banco de dados de origem. Essa instância de banco de dados de réplica de leitura é uma réplica física criada de maneira assíncrona da instância de banco de dados de origem. Isso significa que, às vezes, a réplica não consegue acompanhar a instância de banco de dados primária. Como resultado, podem ocorrer atrasos na replicação. O banco de dados de réplica é criado por uma conexão especial que transmite os dados de write ahead log (WAL – log de gravação antecipada) da instância de banco de dados de origem para a réplica de leitura. Portanto, a réplica de leitura verifica os logs do WAL para replicar as alterações feitas na instância primária. Quando a réplica de leitura não consegue encontrar o WAL na instância primária, a réplica de leitura é recuperada dos dados de WAL arquivados no Amazon Simple Storage Service (Amazon S3). Para obter mais informações, consulte How streaming replication works for different RDS for PostgreSQL versions (Como funciona a replicação de streaming para diferentes versões do RDS para PostgreSQL).

Você pode monitorar o atraso da replicação no Amazon CloudWatch visualizando a métrica ReplicaLag do Amazon RDS. Essa métrica mostra até que ponto uma réplica de leitura ficou atrasada com relação à sua instância de banco de dados de origem. O Amazon RDS monitora o status de replicação da réplica de leitura. Em seguida, ele atualizará o campo Replication State (Estado da replicação) no console do Amazon RDS para Error (Erro) se a replicação for interrompida por qualquer motivo. A métrica ReplicaLag indica até que ponto uma réplica de leitura está acompanhando a instância de banco de dados de origem e a quantidade de latência entre a instância de banco de dados de origem e uma instância de leitura específica.

Resolução

Você poderá ver um dos seguintes erros nos logs de erros do RDS para PostgreSQL quando o atraso da réplica aumentar:

  • Streaming replication has stopped (A replicação de streaming foi interrompida): você recebe este erro quando a replicação de streaming entre as instâncias primária e de réplica é interrompida. Nesse caso, a replicação começa a ser reproduzida do local de arquivamento no Amazon S3, levando a um aumento ainda maior do atraso da réplica.
  • Streaming replication has been terminated (A replicação de streaming foi encerrada): você recebe este erro quando a replicação é interrompida por mais de 30 dias consecutivos manualmente ou em decorrência de um erro de replicação. Nesse caso, o Amazon RDS encerra a replicação entre a instância de banco de dados primária e todas as réplicas de leitura para evitar o aumento dos requisitos de armazenamento na instância primária e tempos de failover mais longos.

A instância da réplica de leitura está disponível mesmo após o encerramento da replicação. No entanto, a replicação não pode ser retomada porque os logs de transação exigidos pela réplica de leitura são excluídos da instância primária após o encerramento da replicação.

Os motivos mais comuns para aumentos no atraso da réplica são os seguintes:

  • Diferenças de configuração entre as instâncias primária e de réplica
  • Workload de gravação pesada na instância primária
  • Transações que estão sendo executadas por muito tempo
  • Bloqueio exclusivo nas tabelas de instâncias primárias
  • Arquivo WAL corrompido ou ausente
  • Problemas de rede
  • Configuração incorreta de parâmetros
  • Nenhuma transação

Diferenças de configuração entre a instância primária e a réplica de leitura

Configurações incorretas da instância de réplica podem afetar o desempenho da replicação. A réplica de leitura lida com uma workload de gravação semelhante à da instância de origem, juntamente com consultas de leitura adicionais. Portanto, use réplicas de uma classe de instância e tipo de armazenamento iguais ou superiores aos da instância de origem. Como a réplica deve reproduzir a mesma atividade de gravação que a instância de origem, o uso de uma réplica de classe de instância inferior pode causar alta latência para a réplica e aumentar o atraso da replicação. Configurações de armazenamento incompatíveis também aumentam o atraso da replicação.

Workload de gravação pesada na instância primária

Uma workload de gravação pesada na instância primária pode criar um alto fluxo de arquivos WAL. Um aumento no número de arquivos WAL e a repetição desses arquivos em réplicas de leitura podem reduzir o desempenho geral da replicação. Portanto, quando você observar um aumento no atraso da réplica, verifique a atividade de gravação na instância primária. Você pode usar métricas do CloudWatch ou monitoramento avançado para analisar essa workload. Visualize os valores de TransactionLogsDiskUsage, TransactionLogsGeneration, WriteIOPS, WriteThroughput e WriteLatency para descobrir se a instância de origem está submetida a uma workload de gravação pesada. Você também pode verificar se há gargalos no nível de throughput. Cada tipo de instância possui seu throughput dedicado. Para obter mais informações, consulte Especificações de hardware para classes de instância de banco de dados.

Para evitar esse problema, controle e distribua a atividade de gravação da instância de origem. Em vez de executar muitas atividades de gravação em conjunto, divida sua tarefa em pacotes de tarefas menores e, em seguida, distribua esses pacotes uniformemente em várias transações. Você pode usar alertas do CloudWatch para métricas, como Writelatency e WriteIOPS, para receber notificações sobre gravações pesadas na instância de origem.

Transações que estão sendo executadas por muito tempo

As transações ativas que estão sendo executadas por muito tempo no banco de dados podem interferir no processo de replicação do WAL aumentando, portanto, o atraso da replicação. Portanto, monitore o tempo de execução das transações ativas com a visualização pg_stat_activity do PostgreSQL.

Execute uma consulta na instância primária semelhante à seguinte para encontrar o ID do processo (PID) da consulta que está sendo executada há muito 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';

Depois de identificar o PID da consulta, você pode optar por encerrar a consulta.

Execute uma consulta na instância primária semelhante à seguinte para encerrar a consulta:

SELECT pg_terminate_backend(PID);

Você também pode optar por regravar ou ajustar a consulta para evitar transações que estejam em execução por muito tempo.

Bloqueio exclusivo nas tabelas de instâncias primárias

Quando você executa comandos, como DROP TABLE, TRUNCATE, REINDEX, VACUUM FULL, REFRESH MATERIALIZED VIEW (sem CONCURRENTLY) na instância primária, o PostgreSQL processa um bloqueio de acesso exclusivo. Esse bloqueio impede que todas as outras transações acessem a tabela durante o bloqueio. Normalmente, a tabela permanece bloqueada até que a transação seja encerrada. Essa atividade de bloqueio é registrada no WAL e, em seguida, é reproduzida e mantida pela réplica de leitura. Quanto mais tempo a tabela permanecer sob um bloqueio de acesso exclusivo, maior será o atraso da replicação.

Para evitar esse problema, é uma prática recomendada monitorar as transações consultando periodicamente as tabelas de catálogo pg_locks e pg_stat_activity.

Exemplo:

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;

Arquivo WAL corrompido ou ausente

Um arquivo WAL corrompido ou ausente pode resultar em atraso na réplica. Nesse caso, você observa um erro nos logs do PostgreSQL informando que o WAL não pode ser aberto. Você também pode observar o erro “requested WAL segment XXX has already been removed” (o segmento XXX solicitado do WAL já foi removido).

Problemas de rede

Uma interrupção de rede entre as instâncias primária e de réplica pode causar problemas com a replicação de streaming que podem resultar no aumento do atraso da réplica.

Configuração incorreta de parâmetros

A definição incorreta de alguns dos parâmetros personalizados no grupo de parâmetros de configuração do servidor pode causar aumento no atraso da réplica. A seguir, são mostrados alguns dos parâmetros que você deve definir corretamente:

  • wal_keep_segments: este parâmetro especifica o número de arquivos WAL que a instância primária mantém no diretório pg_wal. O valor padrão desse parâmetro é definido como 32. Se esse parâmetro não for definido com um valor suficientemente alto para sua implantação, a réplica de leitura poderá ficar atrasada, fazendo com que a replicação de streaming seja interrompida. Nesse caso, o RDS gera um erro de replicação e inicia a recuperação na réplica de leitura ao reproduzir os dados de WAL arquivados da instância primária no S3. Esse processo de recuperação prossegue até que a réplica de leitura possa continuar a replicação de streaming.
    Observação: no PostgreSQL versão 13, o parâmetro wal_keep_segments é denominado wal_keep_size. Esse parâmetro serve ao mesmo propósito que wal_keep_segments. No entanto, o valor padrão desse parâmetro é definido em MB (2048 MB) em vez de no número de arquivos.
  • max_wal_senders: este parâmetro especifica o número máximo de conexões que a instância primária pode suportar ao mesmo tempo por meio do protocolo de replicação de streaming. O valor padrão desse parâmetro do RDS para PostgreSQL 13 e versões superiores é 20. Esse parâmetro deve ser definido com um valor ligeiramente superior ao número real de réplicas de leitura. Se esse parâmetro for definido com um valor inferior ao número de réplicas de leitura, a replicação será interrompida.
  • hot_standby_feedback: este parâmetro especifica se a instância de réplica envia feedback à instância primária sobre consultas que estão sendo executadas atualmente na instância de réplica. Ao ativar esse parâmetro, você seleciona a seguinte mensagem de erro na instância de origem e adia a operação VACUUM em tabelas relacionadas, a menos que a consulta de leitura na instância de réplica seja concluída. Portanto, uma instância de réplica com hot_standby_feedback ativado pode atender a consultas de longa duração. No entanto, esse parâmetro pode sobrecarregar as tabelas na instância de origem. Monitore as consultas de longa duração nas instâncias de réplica para evitar problemas graves, como falta de espaço de armazenamento e esgotamento de numeração de IDs de transação na instância primária.
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: você pode habilitar parâmetros, como max_standby_archive_delay ou max_standby_streaming_delay, na instância de réplica para concluir consultas de leitura de longa duração. Esses parâmetros pausarão a reprodução do WAL na réplica se os dados de origem forem modificados quando as consultas de leitura estiverem sendo executadas na réplica. Um valor de -1 para esses parâmetros permite que a reprodução do WAL aguarde até que a consulta de leitura seja concluída. No entanto, essa pausa aumenta o atraso de replicação indefinidamente e causa alto consumo de armazenamento na origem devido ao acúmulo de WAL.

Nenhuma transação

Se nenhuma transação de usuário estiver ocorrendo na instância de banco de dados de origem, a réplica de leitura do PostgreSQL relatará um atraso de replicação de até cinco minutos.


Informações relacionadas

Trabalhar com réplicas de leitura para o Amazon RDS para PostgreSQL

Documentação do PostgreSQL para configuração do servidor

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos