Os bancos de dados do Grupo de Disponibilidade Distribuída do SQL Server não são sincronizados após a reinicialização do servidor

Estamos nos preparando para executar uma grande atualização em nossos servidores SQL e percebemos algum comportamento incomum com os Grupos de Disponibilidade Distribuída que estou tentando resolver antes de avançar.

No mês passado, atualizei um servidor secundário remoto do SQL Server 2016 para o SQL Server 2017. Este servidor faz parte de vários DAGs (Distributed Availability Groups) e de um Grupo de Disponibilidade (AG) separado . Quando atualizamos este servidor, não tínhamos consciência de que ele entraria em um estado ilegível ; portanto, durante o mês passado, dependemos apenas do servidor principal.

Como parte da próxima atualização, apliquei o patch da CU 4 no servidor e o reinicializei. Quando o servidor voltou a ficar on-line, o secundário corrigido mostrou que todos os DAGs / AGs estavam sincronizando sem problemas.

No entanto, o primário estava mostrando uma história muito diferente. Foi relatando que

• o AG separado estava sincronizando sem problemas
• mas os DAGs estavam em uma Not Synchronzing / Não Saudável estado

Depois de entrar em pânico inicialmente, tentei o seguinte para sincronizar as coisas novamente nos DAGs:

• Do primário, parei e retomei a movimentação de dados. Isso não começou a sincronizar os dados.
• No secundário (o que acabei de corrigir), executei ALTER DATABASE [<database] SET HADR RESUME;- que é executado sem erros, mas não retomou a sincronização

Minha última tentativa de sincronizar os dados novamente foi fazer login no secundário e reiniciar manualmente o serviço do SQL Server. Reiniciar manualmente o serviço parece um pouco extremo, pois eu esperaria que o servidor sendo reinicializado fosse suficiente.

Alguém já encontrou esse problema em que um DAG não inicia a sincronização com um secundário após uma reinicialização? Se sim, como foi resolvido?

Verifiquei o log de erros do SQL Server e o visualizador de eventos no servidor secundário. Não havia nada fora do comum que eu pudesse ver.

Observe que esta não é uma resposta definitiva, mas é a melhor resposta após conversar com Taryn .

No entanto, o primário estava mostrando uma história muito diferente. Ele relatava que o AG separado estava sincronizando sem problemas, mas os DAGs estavam em um estado Não sincronizando / Não íntegro

Se os bancos de dados individuais e os AGs subjacentes ao agente distribuído dizem que estão saudáveis ​​e sincronizados, há uma boa chance de que isso seja apenas um problema nos painéis DMVs e / ou SSMS. Como não havia nada no log de erros que sugerisse que a réplica não se conectou ou estava em um estado desconectado.

Infelizmente, desde que o problema foi resolvido, é difícil dizer exatamente o que era ... mas, no futuro, se isso ocorrer para alguém:

• Verifique sys.dm_hadr_database_replica_states em todos os clusters procurando algo que não esteja íntegro. Se tudo parecer saudável, é possível que o DMV ainda não tenha sido atualizado
• Se não estiver íntegro, verifique o log de erros / DMVs quanto a problemas de conectividade (como não conseguir conectar-se ao encaminhador / primário global)
• A resposta de Dan menciona problemas que podem surgir na inicialização do banco de dados - embora, neste caso, a instância não possa ser lida, o que provavelmente não foi um problema, mas poderia estar no seu caso
• Se o banco de dados estiver legível, teste de fumaça com uma tabela / inserção fictícia ou ...
• Sessão de evento estendida usando os itens do canal DEBUG sqlserver.hadr_dump_log_blockou sqlserver.hadr_apply_log_blockpara ver se o secundário está realmente recebendo / aplicando os blocos de log ou ...
• Objeto perfmon SQLServer:Database Replica\Log Bytes Received/sec

Se você está recebendo dados nesse secundário, mas o distribuidor distribuído ainda mostra que não está sincronizando ou não está íntegro, deixo um pouco para ver se os valores do DMV mudam, pois obviamente estão recebendo e processando blocos de log.

Se, no entanto, não for, precisaremos investigar melhor o que está fora do escopo da resposta.

Eu prefácio tudo isso com a ressalva de que não tenho nenhum DAGs em produção. Fundamentalmente, esse conselho deve ser aplicado entre os AGs e os DAGs.

A sincronização foi retomada após a reinicialização do serviço? Nesse caso, meu melhor palpite para a causa seria o bloqueio no SPID refazer. Se ainda não estiver sincronizando, mesmo após a reinicialização, eis o que eu verificaria primeiro:

Bloqueio de AG refazer SPID

Geralmente, isso só ocorre em um secundário legível. Para verificar, execute o seguinte:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Se algum SPID de bloqueio aparecer, será necessário eliminá-lo antes que o secundário possa continuar (o DB STARTUPSPID é o que lida com as operações de refazer). Sugiro que você revise o SPID de bloqueio com antecedência para tentar determinar a causa (geralmente um relatório de longa duração).

Se você quiser obter mais informações sobre isso, há um ótimo artigo (incluindo o monitoramento para esse tipo de comportamento usando XEs) aqui .

Verificar DMVs

Se a movimentação de dados estiver suspensa, você poderá consultar as DMVs para obter mais informações sobre o motivo da suspensão. Execute o seguinte:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

O artigo BOL descreve um pouco mais o suspend_reason.

O seu Grupo de Disponibilidade Distribuída (DAG) está dividido entre diferentes regiões? Nesse caso, você pode estar sofrendo com o valor padrão de SESSION_TIMEOUT (10 segundos) sendo muito baixo. Isso significa que a latência entre as duas regiões é muito alta para concluir a sincronização com segurança.

Um grupo de disponibilidade normal pode ter seu valor SESSION_TIMEOUT aumentado para tornar as sessões de sincronização mais estáveis. Notei no final do ano passado que o parâmetro SESSION_TIMEOUT dos DAGs não pôde ser editado. Isso significava que os DAGs eram viáveis ​​apenas para cenários de baixa latência. Registramos um ticket na Microsoft e, no início deste ano, um hotfix foi lançado.

Melhoria: Configure o valor SESSION_TIMEOUT para uma réplica do Grupo de Disponibilidade Distribuída no SQL Server 2016 e 2017