Temos um grupo de disponibilidade que consiste em 42 bancos de dados com uma réplica síncrona e uma réplica assíncrona. A réplica síncrona é capaz de acompanhar a primária (por definição), mas a maioria dos bancos de dados na réplica assíncrona efetivamente congela seu progresso no início do dia útil e não faz progresso até perto do fim do dia útil. Abaixo está um gráfico mostrando o atraso do AG por banco de dados, calculado last_commit_timepor sys.dm_hadr_database_replica_states
Para a maioria dos bancos de dados, o last_commit_timefica por volta das 9:00 AM até quase o fim do dia útil. A citação abaixo é de Troubleshoot: Potential data loss with asynchronous-commit availability-group replicas
As seções a seguir descrevem as causas comuns para alto potencial de perda de dados de uma réplica secundária de confirmação assíncrona, supondo que você não tenha um problema de desempenho sistêmico na sua instância de servidor que não esteja relacionado a grupos de disponibilidade.
Alta latência de rede ou baixa taxa de transferência de rede causa acúmulo de log na réplica primária
O gargalo de E/S do disco retarda o endurecimento do log na réplica secundária
Cerca de metade dos bancos de dados usam os arquivos de dados do SQL Server no recurso Microsoft Azure. O desempenho de E/S é muito ruim para esses bancos de dados a ponto de às vezes eu ver avisos de E/S de 15 segundos no log de erros. A parte que me confunde é que a maioria dos bancos de dados com o pior atraso não está no armazenamento do Azure. O único padrão que consigo ver é que os bancos de dados com o melhor desempenho de E/S parecem ter o maior atraso.
Considerando vários bancos de dados em um grupo de disponibilidade, é possível que um banco de dados com baixo desempenho de E/S cause atraso em um banco de dados com bom desempenho de E/S?
Alguns detalhes técnicos adicionais sobre minha situação, se necessário:
A versão do SQL Server é Microsoft SQL Server 2019 (RTM-CU30).
O data center que hospeda a réplica assíncrona está a 1800 milhas de distância do primário. Ambos os data centers estão nos EUA.
O ping da réplica assíncrona para o primário é de 40-50 ms. Já me disseram muitas vezes que não estamos atingindo algum tipo de limitação geral de throughput de rede. Um teste netttcp mostra capacidade de largura de banda de 25-30 Mbit/seg.
De acordo com o
hadr_database_flow_control_actionevento estendido, os bancos de dados que não fazem progresso durante o dia útil gastam efetivamente 100% do tempo esperando no controle de fluxo. Os bancos de dados com menos lag não gastam tempo esperando no controle de fluxo.De acordo com o
hadr_transport_flow_control_actionevento estendido, não há nenhuma espera no controle de fluxo no nível de transporte. OSends to Transport/seccontador perfmon parece validar isso.O sinalizador de rastreamento 12310 foi habilitado de qualquer maneira e não teve nenhum efeito perceptível.
A latência de gravação para os bancos de dados assíncronos com armazenamento não no Azure é entre 1-10 ms. A latência de gravação para os bancos de dados com armazenamento no Azure chega a 400 ms.
Usando o
Bytes Sent to Replica/seccontador perfmon, a réplica assíncrona consegue manter o ritmo até por volta das 8:30 da manhã. Depois, ela fica para trás e só recupera o atraso depois de algumas grandes explosões de progresso após horas.
- O
Log Bytes Flushed/seccontador perfmon (dados ausentes por parte do dia) parece corresponder ao que vemos com bytes enviados. A atividade do usuário final começa a cair por volta das 16h30, que é quando a réplica assíncrona faz mais progresso em recuperação.
- Gerei um relatório de latência AG em 02/06/2025 e os gargalos são envio e controle de fluxo no primário. Não sei como acompanhar esses resultados:
- Estou ciente de que colocar bancos de dados usando os arquivos de dados do SQL Server no recurso Microsoft Azure em um AG assíncrono pode ser uma configuração incomum. Nós efetivamente enviamos os dados 1800 milhas apenas para enviá-los para a nuvem. A documentação da Microsoft sobre o recurso sugere que isso pode não ser necessário:
Benefícios de alta disponibilidade e recuperação de desastres: Usar o recurso SQL Server Data Files no Microsoft Azure pode simplificar as soluções de alta disponibilidade e recuperação de desastres. Por exemplo, se uma máquina virtual no Microsoft Azure ou uma instância do SQL Server travar, você pode recriar seus bancos de dados em uma nova instância do SQL Server apenas restabelecendo links para os blobs.
Executei a ferramenta de relatório AGLatency novamente e coletei dados por dez minutos. A solução de problemas de latência de movimentação de dados entre AlwaysOn Availability Groups de confirmação síncrona descreve como calcular a latência da rede:
Acredito que a
hadr_lsn_send_complete->primary:hadr_receive_harden_lsn_messageetapa não seja executada para uma réplica assíncrona. Fiz meu próprio processamento de dados comparando os timestamps de log de eventos estendidos deprimary:hadr_log_block_send_completeesecondary:hadr_transport_receive_log_block_message. Abaixo estão os resultados resumidos por banco de dados com o nome do banco de dados substituído por se o armazenamento está ou não no Azure:Os dados são classificados pelo número de
hadr_log_block_send_completeeventos da réplica primária. Observe que a latência calculada porsys.dm_hadr_database_replica_statescorresponde muito bem ao número dehadr_log_block_send_completeeventos. Os bancos de dados com o pior atraso enviam a maioria dos blocos de log para a réplica assíncrona. Além disso, os cálculos de latência observados são absolutamente atrozes. Pode levar 15 segundos em média para o secundário receber o bloco de log! Executei ping com configurações não padrão e também consegui observar problemas lá:Minha teoria no momento é que a latência do AG é causada pela alta latência da rede em vez do baixo desempenho de E/S. Os bancos de dados hospedados no armazenamento do Azure com baixo desempenho simplesmente têm uma contagem de transações por segundo menor do que os outros bancos de dados. É por isso que eles têm menos atraso, embora seu desempenho de E/S seja tão ruim. Talvez haja algum tipo de recurso de rede compartilhado que resulta em baixo desempenho durante o horário comercial. Se esse gargalo for resolvido no final do dia útil, isso explica por que a taxa de progresso acelera tanto após o expediente.