Resolver problemas de replicação

O AlloyDB tem uma arquitetura que separa computação e armazenamento, permitindo que cada um seja escalonado de forma independente. Embora as instâncias principais e do pool de leitura compartilhem o mesmo armazenamento subjacente, a replicação ainda é um processo crucial para manter a consistência e a atualização dos dados nas réplicas de leitura. Em um cluster do AlloyDB, as gravações são realizadas na instância principal e registradas no registro de gravação antecipada (WAL). Essas mudanças são replicadas nos nós do pool de leitura. Entender as duas etapas principais desse processo de replicação é fundamental para resolver problemas:

• Liberação do WAL: o registro prévio de gravação (WAL), que contém as mudanças no banco de dados, é enviado da instância principal para a réplica. Em seguida, a réplica persiste imediatamente o WAL no disco.
• Aplicação (ou repetição) do WAL: o WAL persistido é repetido na réplica, ou seja, as mudanças são aplicadas aos caches da réplica.

Atrasos em qualquer uma dessas etapas contribuem para o que é conhecido como atraso de replicação. No entanto, esse termo pode ser ambíguo. Para ser mais preciso, podemos dividir o atraso de replicação nos dois componentes a seguir:

• Flush ou atraso de rede: é o atraso na etapa de flush do WAL. É o tempo necessário para que o WAL seja enviado da instância principal e persistido na réplica.
• Atraso de reprodução: é o atraso na etapa de aplicação do WAL. É o tempo que leva para a réplica aplicar as mudanças do WAL.

A preocupação com o atraso de descarga ou de reprodução depende do seu caso de uso:

• Se você estiver preocupado com a perda de dados, por exemplo, com clusters secundários, preste muita atenção ao atraso de limpeza. Se a WAL ainda não tiver sido persistida na réplica e a instância principal falhar, as mudanças serão perdidas do ponto de vista da réplica.
• Se você se preocupa com a atualização dos dados nas réplicas de leitura, preste atenção ao atraso de descarga e de reprodução. Um atraso em qualquer uma das etapas (transmissão ou aplicação do WAL) resulta em dados desatualizados nas réplicas de leitura.

Verificar o atraso de replicação

É possível monitorar o atraso de replicação das instâncias do pool de leitura no console do Google Cloud . Para mais informações, consulte Monitorar instâncias. Também é possível monitorar o atraso de replicação do pool de leitura e receber alertas em um limite especificado usando Criar políticas de alertas de limite de métrica.

Causas comuns de atraso de replicação

Confira algumas causas comuns do atraso de replicação e como resolver esses problemas.

Contenção de recursos

A replicação também pode ser afetada pela disputa de recursos do sistema, como CPU e memória.

• Pressão de CPU e memória: uma carga de trabalho de leitura pesada em uma instância de pool de leitura pode competir com o processo de replicação por recursos de CPU e memória. É possível verificar o uso de CPU e memória das instâncias no console do Google Cloud . Se você notar uma alta utilização de recursos, talvez seja necessário escalonar verticalmente ou horizontalmente as instâncias do pool de leitura.
• Tamanho do nó do pool de leitura: se a instância principal for muito maior que os nós do pool de leitura, ela poderá gerar registros de replicação mais rápido do que os nós de leitura podem processar. Nesses casos, é recomendável usar nós de leitura maiores para dar mais recursos às réplicas.

Conflitos de replicação

Às vezes, as consultas de leitura podem bloquear o processo de replicação porque retêm recursos que o processo de replicação está aguardando. Se uma consulta de leitura mantiver um bloqueio em um objeto de banco de dados que o processo de repetição precisa atualizar, isso resultará em um conflito de bloqueio. Se uma consulta mantiver um fixador em um buffer de dados que a repetição precisa modificar, isso resultará em um conflito de fixador de buffer. Em ambos os casos, a repetição é bloqueada até que a consulta libere o recurso.

Para identificar esses conflitos, procure mensagens canceling statement due to conflict with recovery no arquivo postgres.log no Explorador de registros.

Para reduzir os conflitos de replicação, faça o seguinte:

• Reduza max_standby_streaming_delay: esse parâmetro determina quanto tempo o processo de repetição espera antes de cancelar as consultas que o estão bloqueando. O valor padrão é de 30 segundos. Reduzir esse valor pode ajudar a diminuir o atraso na replicação, mas também pode causar o cancelamento de mais consultas de leitura. Você pode ajustar esse parâmetro para encontrar o melhor equilíbrio para seu aplicativo.

• Evite consultas de longa duração: consultas de longa duração em pools de leitura podem aumentar a probabilidade de conflitos de replicação. Considere mover consultas de longa duração para outro pool de leitura em que o atraso de replicação baixo não seja tão crítico.

• Verifique se alloydb.promote_cancel_to_terminate está ativo: essa flag, que fica ativada por padrão, permite que o AlloyDB encerre à força back-ends de consultas que não respondem a solicitações de cancelamento. Isso pode ajudar a evitar que back-ends sem resposta bloqueiem a replicação por longos períodos.

Limitação de consultas de leitura com base em atraso

O AlloyDB também permite controlar se a limitação baseada em atraso de consultas de leitura em nós de leitura será ativada usando a flag google_storage.log_replay_throttle_read_transactions. Se o parâmetro estiver definido como o valor padrão de on, as consultas de leitura serão limitadas pausando o início de novas consultas e lendo novos buffers por até um minuto quando o atraso de replicação exceder um segundo. Essa funcionalidade busca um equilíbrio, melhorando a latência de replicação ao fornecer mais recursos de reprodução para que ela se atualize mais rapidamente, ao custo de um possível aumento na latência das consultas de leitura. Se o aplicativo não for sensível ao atraso de replicação, priorize a melhoria da latência de consulta de leitura definindo google_storage.log_replay_throttle_read_transactions como off.

É possível monitorar o impacto da limitação de consultas usando os seguintes métodos:

• Registros: pesquise mensagens Delayed.*due to replica lag no arquivo postgres.log no Explorador de registros para identificar quando as consultas são atrasadas devido ao atraso da réplica.

• Cloud Monitoring: use a métrica alloydb.googleapis.com/instance/postgresql/wait_count para saber quantas consultas foram limitadas. Para fazer isso, filtre a métrica por wait_event_name e procure HighLagThrottle. Para conferir o tempo total em que as consultas foram limitadas, use a métrica alloydb.googleapis.com/instance/postgresql/wait_time com o mesmo filtro. Para mais informações, consulte a referência de métricas de insights do sistema.

• Query Insights: no painel Query Insights, a visualização Consultas ativas mostra o evento de espera HighLagThrottle na coluna Evento de espera quando uma consulta está sendo limitada devido ao atraso na replicação. Para mais detalhes, consulte Monitorar consultas ativas.

Carga de trabalho pesada

Um aumento repentino na carga de trabalho de gravação na instância principal pode gerar uma grande quantidade de registros de replicação, o que pode sobrecarregar as instâncias do pool de leitura e causar atraso na replicação. É possível monitorar o tráfego de gravação na instância principal no console Google Cloud .

Grandes transações

Transações que modificam um grande número de linhas, por exemplo, excluindo várias tabelas ou tabelas grandes, geram registros COMMIT ou ABORT excepcionalmente grandes no registro de gravação antecipada (WAL). Esses registros podem levar um tempo significativo para serem reproduzidos nos nós do pool de leitura, o que causa um aumento temporário no atraso da replicação.

Para evitar isso, não faça operações em lote muito grandes, como exclusões, em uma única transação. Em vez disso, divida essas operações em transações menores e mais frequentes. Isso reduz o tamanho dos registros individuais COMMIT e ABORT, permitindo que o fluxo de replicação permaneça mais fluido e reduzindo o pico de atraso na replicação.

Resolver problemas que impedem a replicação

Para ter um atraso de replicação, é preciso ter um pool de leitura funcionando. Os problemas a seguir podem impedir a replicação, seja impedindo a criação de um pool de leitura ou causando a falha de uma réplica de leitura.

Falhas na instância do pool de leitura

No PostgreSQL 14, uma transação de longa duração na instância principal que contém uma longa lista de bloqueios exclusivos pode aumentar o uso de memória de uma réplica de leitura, o que pode levar à falha da instância do pool de leitura.

Para atenuar esse problema, encerre a transação de longa duração na instância principal.

Impacto do redimensionamento da instância no atraso de replicação

A arquitetura de armazenamento do AlloyDB garante que o atraso de limpeza do pool de leitura não seja afetado pelo redimensionamento da instância. No entanto, o mesmo não se aplica à repetição. A capacidade de reprodução da réplica depende da carga que ela tem. Se você atualizar a configuração da instância, por exemplo, redimensionando-a, dependendo da carga de trabalho, a réplica poderá não ter um cache totalmente aquecido quando a operação for concluída. Isso significa que é mais lento reproduzir ou processar registros que ainda não foram armazenados em cache. Nesse caso, isso pode significar que o atraso de repetição aumenta temporariamente.