Partilhar via

Resolução de problemas de geo-replicação e atraso na recriação

Aplica-se a: Azure SQL Database

Na geo-replicação ativa, a réplica geo-secundária recebe e aplica continuamente registos de registo de transações do primário. Quando a réplica secundária não consegue aplicar logs tão rapidamente quanto o primário os gera, acumula-se um backlog (fila de redo) e o intervalo de tempo aumenta (redo lag). Esta situação pode afetar a atualização em modo somente leitura no servidor secundário e aumentar o tempo de failover.

  • Fila de refazer: O volume de registos de transações que a geo-replicação envia para o secundário, mas ainda não se aplica.
  • Redo lag: O tempo decorrido entre o commit da transação na primária e a conclusão da replay na secundária.

A geo-replicação é assíncrona. O lag de refazer na réplica secundária não causa esperas na primária, mas o lag de refazer pode resultar em dados desatualizados na secundária.

Sintomas

  • Dados obsoletos no secundário para cargas de trabalho apenas de leitura (relatórios, análises ou leituras descarregadas).
  • Tempo de failover mais longo, que aumenta o Objetivo de Tempo de Recuperação (RTO).
  • Pressão sustentada de recursos sobre o sistema secundário, reduzindo a sua capacidade de recuperar terreno.
  • Confirme o atraso de refazer no sys.dm_database_replica_states do DMV, se redo_queue_size > 0 estiver a crescer e secondary_lag_seconds estiver a aumentar.

Porque é que o atraso de refazer aumenta

Embora a base de dados secundária seja apenas de leitura, mantém ainda um registo de transações para operações internas, incluindo a reprodução dos registos do primário. Quando a fila de refazer cresce, o secundário tem de reter mais dados de registo de transações.

Esta situação pode levar a:

  • Crescimento do log de transações no sistema secundário.
  • Maior consumo de armazenamento, o que pode afetar custos e desempenho.
  • Cenários potenciais de limitação quando os limiares são ultrapassados.

Impacto do desajuste de tamanho das réplicas

Deve configurar a réplica primária e geo-secundária com o mesmo objetivo de nível de serviço (SLO), redundância de armazenamento de backup, nível de computação (provisionado ou serverless) e tamanho de computação (DTUs ou vCores).

Se configurar uma base de dados secundária com um tamanho de computação inferior ao da base de dados principal, poderá experienciar:

  • Conflito de recursos no secundário (CPU, I/O), que atrasa as operações de redo.
  • Incapacidade de acompanhar a taxa de geração de registos de transações do primário.
  • Aumento do tamanho da fila de revisão, o que agrava a latência e reduz a eficácia da replicação.

Recommendations

Para reduzir o atraso de refazer e manter a saúde da replicação e o uso eficiente dos logs no secundário:

  • Alinhar o SLO e calcular os tamanhos. Garantir que a base de dados secundária tem o mesmo nível de desempenho que a primária.

  • Monitorize regularmente. Utilize vistas de gestão dinâmica (DMVs) como sys.dm_database_replica_states para acompanhar o atraso de recuperação e o tamanho da fila. O atraso de refazer é confirmado quando redo_queue_size > 0 está a aumentar e secondary_lag_seconds também está a aumentar.

  • Otimize as cargas de trabalho:

    • Reduzir transações de longa duração no secundário e picos elevados de geração de logs no primário.
      • Evite grandes reconstruções de índice durante os horários de pico. As rebuilds podem adquirir bloqueios de modificação de esquema (SCH-M), que podem bloquear o trabalho de redo no secundário e contribuir para o acúmulo na fila de redo.

Conteúdo relacionado

  • Last updated on