Determine por que as alterações da réplica primária não são refletidas na réplica secundária de um Grupo de Disponibilidade AlwaysOn

Aplica-se a:SQL Server

O aplicativo cliente conclui uma atualização na réplica primária com êxito, mas uma consulta à réplica secundária mostra que a alteração não foi refletida. Este caso pressupõe que sua disponibilidade tenha um estado de sincronização saudável. Na maioria dos casos, esse comportamento se resolve após alguns minutos.

Se as alterações ainda não estiverem refletidas na réplica secundária depois de alguns minutos, poderá haver um gargalo no fluxo de trabalho de sincronização. A localização do gargalo depende de a réplica secundária estar configurada para confirmação síncrona ou confirmação assíncrona.

Confirmação síncrona

Cada atualização bem-sucedida na réplica primária já foi sincronizada com a réplica secundária, ou os registros de log já foram liberados para proteção na réplica secundária. Portanto, o gargalo deve estar no processo de redo, que ocorre depois que o log é gravado na réplica secundária.

No entanto, assim que a fase refazer é compensada, todas as cargas de trabalho de leitura da réplica secundária são consultas de isolamento de instantâneo:

  • Transações de longa execução na réplica primária

  • Fase refazer na réplica secundária

Confirmação assíncrona

Como o commit assíncrono confirma uma transação assim que ela é gravada no disco local, o gargalo pode estar em qualquer ponto após isso:

  • Transações de longa execução na réplica primária

  • Latência ou taxa de transferência de rede

  • Proteção de log na réplica secundária

  • Refazer na réplica secundária

As seções a seguir descrevem as causas comuns porque as alterações na réplica primária não são refletidas na réplica secundária em consultas somente leitura.

Transações ativas de longa duração

Uma transação de longa duração na réplica primária impede que as atualizações sejam lidas na réplica secundária.

Explicação

Todas as cargas de trabalho de leitura na réplica secundária são consultas de isolamento de instantâneo. No isolamento de instantâneo, os clientes somente de leitura veem o banco de dados de disponibilidade na réplica secundária no ponto inicial da transação ativa mais antiga no log de redo. Se uma transação não for confirmada em algumas horas, a transação aberta impedirá todas as consultas somente leitura de ver as novas atualizações.

Diagnóstico e resolução

Na réplica primária, use DBCC OPENTRAN (Transact-SQL) para exibir as transações ativas mais antigas e ver se elas podem ser revertidas. Depois que as transações ativas mais antigas são revertidas e sincronizadas com a réplica secundária, as cargas de trabalho de leitura na réplica secundária podem ver as atualizações no banco de dados de disponibilidade até o início da transação ativa mais antiga até então.

Alta latência da rede ou baixa taxa de transferência de rede causa o acúmulo de log na réplica primária

A alta latência ou baixa taxa de transferência da rede pode impedir que os logs sejam enviados à réplica secundária com a rapidez necessária.

Explicação

A réplica primária ativa o controle de fluxo no envio de log quando ele excede o número máximo permitido de mensagens não confirmadas enviadas para a réplica secundária. Até que algumas dessas mensagens sejam confirmadas, não poderão ser enviados mais blocos de log para a réplica secundária. Essa situação pode ter um impacto mais sério sobre a possível perda de dados, podendo comprometer seu objetivo de ponto de recuperação (RPO).

Diagnóstico e resolução

Um valor alto na DMV log_send_queue_size pode indicar que os logs estão sendo retidos na réplica primária. A divisão desse valor por log_send_rate poderá fornecer uma estimativa aproximada de quanto tempo levará para os dados serem compensados na réplica secundária.

Além disso, também é útil verificar os dois objetos de desempenho SQL Server:Availability Replica > Tempo de controle de fluxo (ms/sec) e SQL Server:Availability Replica > Controle de fluxo/seg. A multiplicação desses dois valores mostra quanto tempo foi gasto no último segundo aguardando a liberação do controle de fluxo. Quanto maior o tempo de espera do controle de fluxo, menor será a taxa de envio.

Abaixo está uma lista de métricas úteis no diagnóstico de taxa de transferência e latência de rede. Você pode usar outras ferramentas do Windows, como ping.exe para avaliar a utilização de rede.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Contador de desempenho SQL Server:Database > Log Bytes Flushed/sec

  • Contador de desempenho SQL Server:Database Mirroring > Send/Receive Ack Time

  • Contador de desempenho SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Contador de desempenho SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Contador de desempenho SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Contador de desempenho SQL Server:Availability Replica > Flow Control/sec

  • Contador de desempenho SQL Server:Availability Replica > Resent Messages/sec

Para corrigir esse problema, tente atualizar a largura de banda da sua rede ou remover ou reduzir o tráfego de rede desnecessário.

Outra carga de trabalho de geração de relatórios impede a execução da thread de redo

A thread de redo na réplica secundária está impedida de realizar alterações de DDL (linguagem de definição de dados) por uma consulta somente leitura de longa duração. A thread de redo deve ser desbloqueada antes que possa disponibilizar novas atualizações para a carga de trabalho de leitura.

Explicação

Na réplica secundária, as consultas somente para leitura adquirem bloqueios de estabilidade do esquema (Sch-S). Esses bloqueios Sch-S podem impedir o thread de redo de adquirir bloqueios de modificação de esquema (Sch-M) para realizar quaisquer alterações de DDL. Uma thread de redo bloqueada não pode aplicar registros do log até ser desbloqueada.

Diagnóstico e resolução

Quando a thread de redo é bloqueada, um evento estendido chamado sqlserver.lock_redo_blocked é gerado. Além disso, você pode consultar o sys.dm_exec_request do DMV na réplica secundária para descobrir qual sessão está bloqueando o thread REDO e, em seguida, tomar uma ação corretiva. A consulta a seguir retorna a ID de sessão da carga de trabalho de relatório que está bloqueando o thread refazer.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Você pode permitir que a carga de trabalho de relatório seja concluída, momento em que o thread refazer é desbloqueado, ou pode desbloquear imediatamente o thread refazer executando o comando KILL (Transact-SQL) na ID de sessão que está bloqueando.

A thread de redo fica atrasada devido à contenção de recursos

Uma grande carga de geração de relatórios na réplica secundária prejudicou o desempenho da réplica secundária, e a thread de redo ficou para trás.

Explicação

Ao aplicar registros de log na réplica secundária, a thread de redo lê os registros de log do disco de log e, em seguida, para cada registro de log, acessa as páginas de dados para aplicá-lo. O acesso à página pode ser limitado por E/S (ao acessar o disco físico) se a página ainda não estiver no pool de buffers. Se houver uma carga de trabalho de relatórios limitada por E/S, essa carga de trabalho competirá por recursos de E/S com o thread de redo e poderá desacelerar o thread de redo. Essa situação não apenas impede que outras cargas de trabalho de geração de relatórios visualizem dados atualizados, mas também afeta o RTO.

Diagnóstico e resolução

Você pode usar a seguinte consulta DMV para ver o quanto o thread de redo ficou atrasado, medindo a diferença no intervalo entre last_redone_lsn e last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Se a thread de redo estiver de fato atrasada, você precisará investigar a causa raiz da degradação do desempenho na réplica secundária. Se houver uma contenção de E/S com a carga de trabalho de relatório, você poderá usar o Resource Governor para controlar os ciclos de CPU que são usados pela carga de trabalho de relatório para controlar indiretamente os ciclos de E/S executados, até certo ponto. Por exemplo, se sua carga de trabalho de geração de relatórios estiver consumindo 10% da CPU, mas estiver limitada por E/S, você poderá usar o Resource Governor para limitar o uso de recursos de CPU a 5% a fim de reduzir a carga de trabalho de leitura, o que minimiza o impacto sobre a E/S.

Conteúdo relacionado

  • Última atualização em