O AlloyDB tem uma arquitetura que separa a computação e o armazenamento, o que permite que cada um seja dimensionado de forma independente. Embora as instâncias do pool principal e de leitura partilhem o mesmo armazenamento subjacente, a replicação continua a ser um processo crucial para manter a consistência e a atualidade dos dados nas réplicas de leitura. Num cluster do AlloyDB, as escritas são realizadas na instância principal e, em seguida, registadas no registo de transações (WAL) no armazenamento partilhado. Depois, estas alterações são replicadas para as caches na memória das instâncias do conjunto de leitura. A compreensão dos dois passos principais deste processo de replicação é fundamental para resolver quaisquer problemas:
Libertação do WAL: o registo de escrita antecipada (WAL), que contém as alterações à base de dados, é enviado do servidor principal para a réplica. Em seguida, a réplica persiste imediatamente o WAL no disco. Os atrasos em qualquer um destes passos contribuem para o que é conhecido como atraso de replicação. No entanto, este termo pode ser ambíguo. Para ser mais preciso, podemos dividir o atraso da replicação nos dois componentes seguintes:
Libertação ou atraso da rede: este é o atraso no passo de libertação do WAL. É o tempo que o WAL demora a ser enviado a partir do servidor principal e persistido na réplica.
Atraso na repetição: este é o atraso no passo de aplicação do WAL. É o tempo que a réplica demora a aplicar as alterações do WAL.
Se deve preocupar-se mais com o atraso de descarga ou o atraso de repetição depende do seu exemplo de utilização:
- Se tiver preocupações com a perda de dados, por exemplo, com réplicas entre regiões, tem de prestar muita atenção ao atraso de descarga. Se o WAL ainda não estiver persistido na réplica e o primário falhar, as alterações são perdidas na perspetiva da réplica.
- Se estiver preocupado com a atualidade dos dados nas suas réplicas de leitura, tem de prestar muita atenção ao atraso de repetição. Um intervalo de tempo elevado significa que os dados nas réplicas de leitura estão desatualizados.
Verifique se existe um atraso na replicação
Pode monitorizar o atraso de replicação das instâncias do conjunto de leitura na Google Cloud consola. Para mais informações, consulte o artigo Monitorize instâncias. Também pode monitorizar o atraso da replicação do conjunto de leitura e receber alertas num limite especificado através da opção Criar políticas de alerta de limite de métricas.
Causas comuns do atraso na replicação
Seguem-se algumas causas comuns do atraso na replicação e como resolvê-las.
Conflito de recursos
A replicação também pode ser abrandada pela contenção de recursos do sistema, como a CPU e a memória.
- Pressão da CPU e da memória: uma carga de trabalho de leitura pesada numa instância de pool de leitura pode competir com o processo de replicação por recursos de CPU e memória. Pode verificar a utilização de memória e CPU das suas instâncias na Google Cloud consola. Se vir uma utilização elevada de recursos, pode ter de aumentar verticalmente ou horizontalmente as instâncias do conjunto de leitura.
- Tamanho do nó do conjunto de leitura: se a instância principal for muito maior do que os nós do conjunto de leitura, pode gerar registos de replicação mais rapidamente do que os nós de leitura os conseguem processar. Nestes casos, é recomendado usar nós de leitura de maior dimensão para dar mais recursos às réplicas.
Conflitos de replicação
Por vezes, as consultas de leitura podem bloquear o processo de replicação porque retêm recursos que o processo de replicação está a aguardar. Por exemplo, se uma consulta de leitura tiver um bloqueio num objeto de base de dados que o processo de replicação precisa de atualizar, a replicação é bloqueada até que o bloqueio seja libertado. Estes são conhecidos como conflitos de PINs de buffer.
Pode identificar estes conflitos procurando mensagens canceling statement due to conflict with recovery no ficheiro postgres.log no Explorador de registos.
Para mitigar conflitos de replicação, pode fazer o seguinte:
Reduzir
max_standby_streaming_delay: este parâmetro determina o tempo que o processo de replicação aguarda antes de cancelar as consultas que o estão a bloquear. O valor predefinido é 30 segundos. Reduzir este valor pode ajudar a reduzir o intervalo de tempo da replicação, mas também pode fazer com que mais consultas de leitura sejam canceladas. Pode ajustar este parâmetro para encontrar o melhor equilíbrio para a sua aplicação.Evite consultas de execução prolongada: as consultas de execução prolongada em conjuntos de leitura podem aumentar a probabilidade de conflitos de replicação. Considere mover as consultas de execução prolongada para um conjunto de leitura diferente, onde o atraso de replicação baixo não é tão crítico.
Ative
alloydb.promote_cancel_to_terminate: este sinalizador, que está ativado por predefinição, permite que o AlloyDB termine à força os back-ends de consultas que não respondem a pedidos de cancelamento. Isto pode ajudar a evitar que os backends sem resposta bloqueiem a replicação durante períodos prolongados.
Limitação temporária de consultas de leitura
O AlloyDB também lhe dá o controlo sobre se deve ativar a limitação baseada no atraso de uma consulta de leitura em nós de leitura através da flag google_storage.log_replay_throttle_read_transactions. Se o parâmetro estiver definido para o valor predefinido de on, as consultas de leitura são limitadas através da pausa do início de novas consultas, bem como da leitura de novos buffers durante um máximo de um minuto quando o atraso de replicação excede um segundo. Esta funcionalidade faz uma compensação que melhora o atraso da replicação, dando à repetição mais recursos para recuperar o atraso mais rapidamente, à custa de um potencial aumento da latência de leitura. Se a sua aplicação não for sensível ao atraso de replicação, pode dar prioridade à melhoria da latência de consultas de leitura definindo google_storage.log_replay_throttle_read_transactions como off.
Pode monitorizar o impacto da limitação de consultas através dos seguintes métodos:
Registos: pesquise mensagens
Delayed.*due to replica lagno ficheiropostgres.logno Explorador de registos para identificar quando as consultas são atrasadas devido ao atraso da réplica.Monitorização na nuvem: use a métrica
alloydb.googleapis.com/instance/postgresql/wait_countpara ver quantas consultas foram limitadas. Para o fazer, filtre a métrica porwait_event_namee procureHighLagThrottle. Para ver o tempo total em que as consultas foram limitadas, pode usar a métricaalloydb.googleapis.com/instance/postgresql/wait_timecom o mesmo filtro. Para mais informações, consulte a referência de métricas de estatísticas do sistema.Estatísticas de consultas: no painel de controlo Estatísticas de consultas, a vista Consultas ativas mostra o evento de espera
HighLagThrottlena coluna Evento de espera quando uma consulta está a ser limitada devido ao atraso na replicação. Para mais detalhes, consulte o artigo Monitorize consultas ativas.
Carga de trabalho elevada
Um aumento repentino na carga de trabalho de escrita na instância principal pode gerar uma grande quantidade de registos de replicação, o que pode sobrecarregar as instâncias do conjunto de leitura e causar um atraso na replicação. Pode monitorizar o tráfego de gravação na sua instância principal na Google Cloud consola.
Transações elevadas
As transações grandes, como registos COMMIT ou ABORT que afetam um grande número de linhas, podem demorar muito tempo a serem replicadas para as instâncias do conjunto de leitura. No PostgreSQL 14, uma transação de execução prolongada que contenha uma longa lista de bloqueios exclusivos pode fazer com que a utilização de memória da réplica de leitura aumente, o que pode levar à falha da instância do conjunto de leitura.
Para mitigar este problema, pode terminar a transação de longa duração na instância principal.
Resolva problemas que impedem a replicação
Antes de poder ter um atraso na replicação, tem de ter um conjunto de leitura funcional. Os seguintes problemas podem impedir a replicação, seja impedindo a criação de um conjunto de leitura ou provocando uma falha na réplica de leitura.
Leia problemas de criação de grupos
Se não for possível criar um conjunto de leitura, pode ver uma mensagem Failed to create read pool nos registos do AlloyDB no Cloud Logging. Isto pode acontecer se o cluster tiver atingido o limite máximo de armazenamento, o que impede a instância principal de atribuir mais espaço. Embora o AlloyDB dimensione automaticamente o armazenamento, pode ter de investigar o que consome armazenamento e eliminar dados desnecessários ou contactar o apoio técnico para pedir um aumento da sua quota de armazenamento.
Ler falhas de instâncias de piscinas
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 a utilização de memória de uma réplica de leitura aumente, o que pode levar à falha da instância do conjunto de leitura.
Para mitigar este problema, pode terminar a transação de longa duração na instância principal.
Impacto do redimensionamento da instância no atraso da replicação
A arquitetura de armazenamento do AlloyDB garante que o atraso de descarga do conjunto de leitura não é afetado pela alteração do tamanho 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 tem. Se atualizar a configuração da instância, por exemplo, redimensionando-a, consoante a carga de trabalho, a réplica pode não ter uma cache totalmente aquecida quando a operação for concluída. Isto significa que é mais lento reproduzir ou processar registos que ainda não foram colocados em cache. Nesse caso, isto pode significar que o atraso na repetição aumenta temporariamente.