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) no armazenamento compartilhado. Essas mudanças são replicadas nos caches na memória das instâncias 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. 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 que leva para o WAL ser 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 necessário 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 réplicas entre regiões, preste muita atenção ao atraso de limpeza. Se a WAL ainda não tiver sido persistida na réplica e o servidor 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 reprodução. Um atraso de reprodução alto significa que os dados nas réplicas de leitura estão desatualizados.
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 na 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 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 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 bloqueiam o processo de replicação porque retêm recursos que o processo de replicação está aguardando. Por exemplo, se uma consulta de leitura tiver um bloqueio em um objeto de banco de dados que o processo de replicação precisa atualizar, a replicação será bloqueada até que o bloqueio seja liberado. Esses problemas são conhecidos como conflitos de fixação de buffer.
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 replicaçã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 diminuir o atraso na replicação, mas também pode causar o cancelamento de mais consultas de leitura. Ajuste 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 um pool de leitura diferente, em que o baixo atraso de replicação não é tão crítico.
Ative
alloydb.promote_cancel_to_terminate: essa flag, que está 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 temporária de consultas de leitura
O AlloyDB também permite controlar se a limitação baseada em atraso de uma consulta 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 o atraso 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 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 lagno arquivopostgres.logno 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_countpara saber quantas consultas foram limitadas. Para fazer isso, filtre a métrica porwait_event_namee procureHighLagThrottle. Para conferir o tempo total em que as consultas foram limitadas, use a métricaalloydb.googleapis.com/instance/postgresql/wait_timecom o mesmo filtro. Para mais informações, consulte a Referência de métricas de insights do sistema.Insights de consulta: no painel Insights de consulta, a visualização Consultas ativas mostra o evento de espera
HighLagThrottlena 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 grandes, como registros COMMIT ou ABORT que afetam um grande número de linhas, podem levar muito tempo para serem replicadas nas instâncias do pool de leitura. No PostgreSQL 14, uma transação de longa duração que mantém uma longa lista de bloqueios exclusivos pode fazer com que o uso de memória da réplica de leitura aumente, 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.
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 uma falha na réplica de leitura.
Problemas na criação de pools de leitura
Se um pool de leitura não for criado, você poderá ver uma mensagem Failed to create read pool nos registros do AlloyDB no Cloud Logging. Isso pode acontecer se o cluster atingir o limite máximo de armazenamento, impedindo que a instância principal aloque mais espaço. Embora o AlloyDB dimensione automaticamente o armazenamento, talvez seja necessário investigar o que consome armazenamento e excluir dados desnecessários ou entrar em contato com o suporte para solicitar um aumento na cota de armazenamento.
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 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 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.