Compartilhar via

Solucionar problemas de replicação geográfica e retardo

Applies to:Azure SQL Database

Na replicação geográfica ativa, a réplica geo-secundária recebe continuamente e aplica registros de log de transações do primário. Quando a réplica secundária não consegue aplicar os logs tão rapidamente quanto o primário os gera, há um acúmulo (fila de reexecução) e o intervalo de tempo aumenta (atraso de reexecução). Essa situação pode afetar a atualização somente leitura no secundário e aumentar o tempo de failover.

  • Fila de repetição: o volume de registros do log de transações que a replicação geográfica manda para o secundário, mas ainda não aplica.
  • Atraso de reexecução: o tempo decorrido entre a confirmação da transação no primário e a conclusão da reexecução no secundário.

A replicação geográfica é assíncrona. O lag de redo na réplica secundária não causa esperas na réplica primária, mas pode fazer com que os dados na secundária fiquem defasados.

Symptoms

  • Dados obsoletos no servidor secundário para cargas de trabalho de leitura (relatórios, análises ou leituras transferidas).
  • Tempo de failover mais longo, o que aumenta o RTO (Objetivo de Tempo de Recuperação).
  • Pressão de recursos sustentada no secundário, reduzindo sua capacidade de acompanhar.
  • Confirme o atraso de repetição no DMV sys.dm_database_replica_states, se redo_queue_size > 0 está crescendo e secondary_lag_seconds está aumentando.

Por que a caixa de pendências de refazer cresce

Embora o banco de dados secundário seja somente leitura, ele ainda mantém um log de transações para operações internas, incluindo a reprodução de registros de log do primário. Quando a fila de refazer aumenta, o secundário deve reter mais dados de log de transações.

Essa situação pode levar a:

  • Crescimento do log de transações no sistema secundário.
  • Maior consumo de armazenamento, o que pode afetar o custo e o desempenho.
  • Cenários possíveis de limitação quando os limites são excedidos.

Impacto da incompatibilidade de tamanho da réplica

Você deve configurar a réplica primária e geográfica secundária com o mesmo SLO (objetivo de nível de serviço), redundância de armazenamento de backup, camada de computação (provisionada ou sem servidor) e tamanho da computação (DTUs ou vCores).

Se você configurar um banco de dados secundário com um tamanho de computação menor que o banco de dados primário, poderá experimentar:

  • Contenção de recursos na unidade secundária (CPU, E/S), o que retarda as operações de reaplicação.
  • Incapacidade de acompanhar a taxa de geração do log de transações do sistema primário.
  • Aumento no tamanho da fila de redo, piorando a latência e reduzindo a eficácia da replicação.

Recomendações

Para reduzir o atraso e manter a saúde da replicação e o uso eficiente do log no servidor secundário:

  • Alinhe os SLOs e os tamanhos da computação. Verifique se o banco de dados secundário tem a mesma camada de desempenho que o primário.

  • Monitore regularmente. Use exibições de gerenciamento dinâmico (DMVs), como sys.dm_database_replica_states, para acompanhar o atraso no redo e o tamanho da fila. O retardo é confirmado quando redo_queue_size > 0 e cresce e secondary_lag_seconds está aumentando.

  • Otimize cargas de trabalho.

    • Reduza as transações de execução prolongada no secundário e os picos altos de geração de log no primário.
      • Evite recompilações de índice grandes durante os horários de pico. As recompilações podem adquirir bloqueios de modificação de esquema (SCH-M), que podem bloquear o thread de refazer no secundário e contribuir para o acúmulo da fila de refazer.

Conteúdo relacionado

  • Last updated on