Resolver problemas de replicação

O AlloyDB tem uma arquitetura que separa a computação e o armazenamento, permitindo que cada um seja escalonado de forma independente. Embora as instâncias principal e do pool de leitura compartilhem o mesmo armazenamento, 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 depois registradas no registro prévio de escrita (WAL). Essas mudanças são replicadas para os 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 escrita (WAL), que contém as alterações no banco de dados, é enviado da instância primária para a réplica. Em seguida, a réplica mantém o WAL no disco imediatamente.
• Aplicação (ou repetição) do WAL: o WAL persistente é repetido na réplica, o que significa que as alterações 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:

• Atraso de transferência ou de rede: é o atraso na etapa de transferência do WAL. É o tempo que leva para o WAL ser enviado do banco de dados principal e mantido na réplica.
• Atraso de repetição: é o atraso na etapa de aplicação do WAL. É o tempo que a réplica leva para aplicar as mudanças do WAL.

A preocupação com o atraso de limpeza ou de repetição depende do seu caso de uso:

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

Verificar se há atraso na 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 de atraso na replicação e como resolvê-las.

Contenção de recursos

A replicação também pode ser retardada pela contenção 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 da CPU e da 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 escalonar 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 rapidamente do que os nós de leitura podem processá-los. Nesses casos, é recomendável usar nós de leitura maiores para dar mais recursos às réplicas.

Conflitos de replicação

As consultas de leitura às vezes podem bloquear o processo de replicação porque elas 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 vai resultar em um conflito de bloqueio. Se uma consulta mantiver um pin em um buffer de dados que a repetição precisa modificar, isso resultará em um conflito de pin 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 na Análise de Registros.

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

• Reduzir max_standby_streaming_delay: esse parâmetro determina quanto tempo o processo de repetição aguarda antes de cancelar as consultas que o estão bloqueando. O valor padrão é de 30 segundos. Reduzir esse valor pode ajudar a reduzir o atraso de replicação, mas também pode fazer com que mais consultas de leitura sejam canceladas. É possível 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 as consultas de longa duração para um pool de leitura diferente, em que um 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 de forma forçada os back-ends de consulta que não respondem às solicitações de cancelamento. Isso pode ajudar a evitar que back-ends que não respondem bloqueiem a replicação por períodos prolongados.

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

O AlloyDB também permite que você controle se quer ativar a limitação com base em atraso de consultas de leitura em nós de leitura usando a flag google_storage.log_replay_throttle_read_transactions. Se o parâmetro estiver definido com 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 da 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 na Análise de Registros para identificar quando as consultas estão atrasadas devido ao atraso da réplica.

• Cloud Monitoring: use a métrica alloydb.googleapis.com/instance/postgresql/wait_count para ver quantas consultas foram limitadas. Para fazer isso, filtre a métrica por wait_event_name e procure HighLagThrottle. Para ver 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 do System Insights.

• Query Insights: no painel do 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 de 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 primária 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 do Google Cloud .

Volume pesado de registros prévios de escrita devido à criação do índice ScaNN

A criação do índice ScaNN pode gerar grandes quantidades de registros WAL de gravações de página inteira. Isso pode causar atrasos no envio de registros WAL da instância principal para as instâncias de leitura. Se o atraso de replicação corresponder à criação do índice ScaNN em um grande número de embeddings, ative wal_compression na instância principal para economizar E/S de rede e disco e reduzir o atraso de replicação. Isso pode gerar uma pequena sobrecarga de CPU extra.

wal_compression compacta apenas registros de gravações de página inteira e não tem efeito na maioria dos registros WAL. A alteração dessa flag não requer uma reinicialização e não tem inatividade.

Transações grandes

As 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 prévio de escrita (WAL, na sigla em inglês). Esses registros podem levar um tempo significativo para serem reproduzidos nos nós do pool de leitura, o que leva a um aumento temporário no atraso de replicação.

Para evitar isso, não realize 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 de COMMIT e ABORT, permitindo que o fluxo de replicação permaneça mais fluido e reduzindo o atraso de replicação de pico.

Resolver problemas que impedem a replicação

Para ter atraso de replicação, é preciso ter um pool de leitura em funcionamento. Os problemas a seguir podem impedir que a replicação ocorra, seja impedindo a criação de um pool de leitura ou causando uma falha na 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 fazer com que o uso da memória de uma réplica de leitura aumente, o que pode levar à falha da instância do pool de leitura.

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

Impacto do redimensionamento de instâncias 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 repetiçã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 pode não ter um cache totalmente aquecido quando a operação for concluída. Isso significa que ele é mais lento para 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.