Início / dba / Perguntas / 200269
Accepted
Taryn
Asked: 2018-03-15 09:12:43 +0800 CST

Bancos de dados do SQL Server Distributed Availability Group não sincronizados após a reinicialização do servidor

  • 772

Estamos nos preparando para realizar uma grande atualização em nossos SQL Servers e estamos percebendo um comportamento incomum com os Grupos de Disponibilidade Distribuídos 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. Esse servidor faz parte de vários Grupos de Disponibilidade Distribuídos (DAGs) e um Grupo de Disponibilidade (AG) separado . Quando atualizamos este servidor, não sabíamos que ele entraria em um estado ilegível , portanto, durante o mês passado, contamos apenas com o servidor primário.

Como parte da próxima atualização, apliquei o patch CU 4 ao servidor e o reiniciei. Quando o servidor voltou a ficar online, o secundário recém corrigido mostrou que todos os DAGs/AGs estavam sincronizando sem problemas.

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

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

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

  • A partir 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) eu corri ALTER DATABASE [<database] SET HADR RESUME;- que executa sem erros, mas não retomou nenhuma sincronização

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

Alguém já se deparou com 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?

Eu 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.

sql-server availability-groups

3 respostas

  1. Best Answer

    Observe que esta não é uma resposta definitiva, mas é a melhor resposta depois de conversar com Taryn .

    No entanto, a primária estava mostrando uma história muito diferente. Estava relatando que o AG separado estava sincronizando sem problemas, mas os DAGs estavam em um estado Não sincronizado / Não saudável

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

    Infelizmente, como 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 por algo que não esteja íntegro. Se tudo estiver saudável, é possível que o DMV ainda não tenha atualizado
    • Se não estiver íntegro, verifique o log de erros/DMVs para problemas de conectividade (como não conseguir se conectar ao encaminhador/principal global)
    • A resposta de Dan menciona problemas que podem surgir da inicialização do banco de dados - embora, neste caso, a instância não possa ser lida, então provavelmente não foi um problema, mas pode ser no seu caso
    • Se o banco de dados for legível, faça um 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 PerfmonSQLServer:Database Replica\Log Bytes Received/sec

    Se você estiver recebendo dados nesse secundário, mas o ag distribuído ainda não estiver sincronizado ou não estiver íntegro, eu deixaria passar um pouco para ver se os valores de DMV mudam, pois obviamente está recebendo e processando blocos de log.

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

    • 9

  2. Vou começar tudo isso com a ressalva de que não tenho nenhum DAG em produção. Fundamentalmente, porém, esse conselho deve ser aplicado entre AGs e DAGs.

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

    Bloqueio de AG refazer SPID

    Geralmente só vai ocorrer 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, você precisará eliminá-lo antes que o secundário possa continuar (o DB STARTUPSPID é o que lida com as operações de redo). Sugiro revisar o SPID de bloqueio com antecedência para tentar determinar a causa (geralmente um relatório de longa duração).

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

    Verifique os DMVs

    Se a movimentação de dados for suspensa, você pode consultar os 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 o suspend_reason um pouco mais.

    • 4

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

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

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

    • 0

relate perguntas