Início / dba / Perguntas / 183208
Accepted
Greg Bray
Asked: 2017-08-11 10:52:19 +0800 CST

Semeadura direta do grupo de disponibilidade distribuído FAILED, failure_state SQL Error, failure_state 2

  • 772

Acabamos de começar a configurar grupos de Disponibilidade Distribuída para replicar nossos bancos de dados de produção em um novo cluster de relatórios. O primeiro grupo de disponibilidade que configuramos para replicação funcionou muito bem sem problemas, no entanto, quando passamos para o segundo grupo de disponibilidade com bancos de dados muito maiores (mais de 3 TB no total), demorou muito mais e dois dos 5 bancos de dados falharam. Configuramos o grupo de disponibilidade distribuído para usar a propagação direta e ao consultar a tabela sys.dm_hadr_automatic_seeding ela indica o current_state como FAILED, com failure_state 2 (Erro SQL) ou 21 (Tempo limite da mensagem de verificação de propagação):

dm_hadr_automatic_seeding

O que podemos fazer para solucionar esse problema?

availability-groups sql-server-2016

2 respostas

  1. Best Answer

    O blog AlwaysOn Professional tem algumas etapas gerais de solução de problemas para propagação direta e também inclui alguns detalhes sobre o sinalizador de rastreamento 9567 para habilitar a compactação durante a propagação, mas não encontrei nenhum detalhe sobre o erro de SQL ou o tempo limite de propagação.

    Anteriormente, tivemos problemas com bancos de dados grandes causando problemas em grupos de disponibilidade, mas isso geralmente é resolvido aplicando os logs de transação mais recentes do primário na réplica .

    Nesse caso, os bancos de dados foram listados no grupo de disponibilidade secundário como em recuperação, então tentei aplicar os backups de log de transações mais recentes do primário e, em seguida, juntar o banco de dados ao grupo de disponibilidade secundário:

    --Restore transaction logs from primary and stay in recovery mode. Multiple backup files may need to be restored from oldest to newest.
RESTORE LOG stackoverflow from disk = '\\Backups\SQL\_Trans\StackOverflow_AG\StackOverflow\StackOverflow_LOG_20170810_175400.trn' WITH NORECOVERY;

ALTER DATABASE stackoverflow SET HADR AVAILABILITY GROUP = [StackOverflow_RAG];
ALTER DATABASE stackoverflow SET HADR RESUME;

    Isso funcionou para os dois bancos de dados com falha e corrigiu os problemas de replicação. Nosso cluster de relatórios agora tem todos os bancos de dados sincronizados com o grupo de disponibilidade primário:

    insira a descrição da imagem aqui

    • 1

  2. Há um bug no SQL Server 2016/2017 que ainda não foi corrigido, basta acertar esse problema no SP2 com CU2. O sinalizador de rastreamento de dúvida 9567 é a solução, pois meus bancos de dados eram pequenos, 1 GB.

    https://support.microsoft.com/en-us/help/4040519/fix-automatic-seeding-in-availability-groups-randomly-causes-error-411

    Observe o number_of_attempts na consulta abaixo, o valor é 1 para mim, espero algumas tentativas antes que a propagação direta desista, mas não faço ideia de onde definir isso.

    USE [master];
SELECT TOP 100 * FROM sys.dm_hadr_automatic_seeding WHERE current_state = 'FAILED' ORDER BY start_time DESC;
    • 0

relate perguntas