Opção de failover para detecção de integridade em nível de banco de dados do grupo de disponibilidade

Aplica-se a:SQL Server

No SQL Server 2016 e versões posteriores, a opção de detecção de integridade no nível do banco de dados (DB_FAILOVER) está disponível na configuração de um grupo de disponibilidade Always On. A detecção de integridade no nível do banco de dados identifica quando um banco de dados deixa de estar online, quando algo dá errado e aciona o failover automático do grupo de disponibilidade. Exemplos que podem acionar a detecção de integridade incluem o banco de dados em modo suspeito, o banco de dados offline e o banco de dados em recuperação (falha na recuperação). Para obter mais informações, consulte a coluna State em sys.databases.

A detecção de integridade no nível do banco de dados está habilitada no grupo de disponibilidade como um todo e, portanto, a detecção de integridade no nível do banco de dados monitora cada banco de dados no grupo de disponibilidade. Ela não pode ser habilitada seletivamente em bancos de dados específicos no grupo de disponibilidade.

Benefícios da opção de detecção de integridade em nível de banco de dados

A opção de detecção de integridade no nível do banco de dados do grupo de disponibilidade é amplamente recomendada como uma boa escolha para ajudar a garantir a alta disponibilidade dos seus bancos de dados. Considere a possibilidade de ativá-la em todos os grupos de disponibilidade. Se o aplicativo depender de vários bancos de dados para estar altamente disponível, agrupe-os em um grupo de disponibilidade com a opção de integridade do banco de dados ativada.

Por exemplo, com a opção de detecção de integridade no nível do banco de dados ativada, se o SQL Server não conseguir gravar no arquivo de log de transações de um dos bancos de dados, o status desse banco de dados será alterado para indicar uma falha e o grupo de disponibilidade fará failover em breve. Além disso, o aplicativo poderá se reconectar e continuar trabalhando com interrupção mínima quando os bancos de dados estiverem online novamente.

Ativando a detecção de saúde em nível de banco de dados

Embora geralmente seja recomendada, a opção Integridade do Banco de Dados está desativada por padrão, em um esforço para manter a compatibilidade das configurações padrão em versões anteriores.

Há várias maneiras fáceis de habilitar a configuração de detecção de integridade no nível do banco de dados:

1. No SQL Server Management Studio, conecte-se ao mecanismo de banco de dados do SQL Server. Usando a janela Pesquisador de Objetos, clique com o botão direito do mouse no nó Alta Disponibilidade Always On e execute o Assistente de Novo Grupo de Disponibilidade. Marque a caixa de seleção Detecção de Integridade em Nível de Banco de Dados na página Especificar Nome. Em seguida, conclua o restante das páginas do assistente.

   

2. Exiba as Propriedades de um Grupo de Disponibilidade existente no SQL Server Management Studio. Conecte-se ao SQL Server. Na janela Gerenciador de Objetos, expanda o nó de Alta Disponibilidade Always On. Expanda os Grupos de Disponibilidade. Clique com o botão direito do mouse no grupo de disponibilidade e escolha Propriedades. Marque a opção Detecção de Integridade no Nível do Banco de Dados e, em seguida, clique em OK ou em Criar script da alteração.

   

3. Sintaxe Transact-SQL para CREATE AVAILABILITY GROUP. O parâmetro DB_FAILOVER aceita valores ON ou OFF.

   CREATE AVAILABILITY GROUP [Contoso-ag]
   WITH (DB_FAILOVER=ON)
   FOR DATABASE [AutoHa-Sample]
   REPLICA ON
       N'SQLSERVER-0' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-0.DOMAIN.COM:5022',
         FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
       N'SQLSERVER-1' WITH (ENDPOINT_URL = N'TCP://SQLSERVER-1.DOMAIN.COM:5022',
        FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

4. Sintaxe Transact-SQL para ALTER AVAILABILITY GROUP. O parâmetro DB_FAILOVER aceita valores ON ou OFF.

   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = ON);
   
   ALTER AVAILABILITY GROUP [Contoso-ag] SET (DB_FAILOVER = OFF);
   

Advertências

É importante observar que, atualmente, a opção Detecção de Integridade no Nível do Banco de Dados não faz com que o SQL Server monitore a disponibilidade do disco, e o SQL Server não monitora diretamente a disponibilidade dos arquivos do banco de dados. Caso uma unidade de disco falhe ou não esteja disponível, isso por si só não necessariamente vai disparar o grupo de disponibilidade para fazer failover de modo automático.

Por exemplo, quando um banco de dados está ocioso sem nenhuma transação ativa e não está ocorrendo nenhuma gravação física, caso alguns dos arquivos do banco de dados fiquem inacessíveis, o SQL Server poderá não executar a E/S de leitura ou gravação para os arquivos nem alterar o status desse banco de dados imediatamente e, portanto, nenhum failover será disparado. Posteriormente, quando ocorrer um ponto de verificação do banco de dados ou ocorrer uma leitura ou gravação física para atender a uma consulta, o SQL Server poderá perceber o problema de arquivo e responder alterando o status do banco de dados e, mais tarde, o grupo de disponibilidade com a detecção de integridade no nível do banco de dados definida como ativada fará failover devido à alteração da integridade do banco de dados.

Como outro exemplo, quando o mecanismo de banco de dados do SQL Server precisar ler uma página de dados para atender a uma consulta, se a página de dados estiver armazenada em cache na memória do pool de buffers, nenhuma leitura de disco com acesso físico poderá ser necessária para atender à solicitação de consulta. Portanto, um arquivo de dados ausente ou não disponível poderá não disparar um failover automático imediatamente, mesmo quando a opção de integridade do banco de dados estiver habilitada, já que o status do banco de dados não é atualizado imediatamente.

O failover de banco de dados é independente da política de failover flexível

A detecção de integridade no nível do banco de dados implementa uma política de failover flexível que configura os limites da integridade do processo do SQL Server para a política de failover. A detecção de integridade no nível do banco de dados é configurada com o parâmetro DB_FAILOVER, enquanto a opção de grupo de disponibilidade FAILURE_CONDITION_LEVEL é separada para configurar a detecção de integridade do processo do SQL Server. As duas opções são independentes.

Gerenciando e monitorando a detecção de integridade no nível do banco de dados

Modos de Exibição de Gerenciamento Dinâmico

A DMV do sistema sys.availability_groups mostra uma coluna db_failover que indica se a opção de detecção de integridade no nível do banco de dados está desativada (0) ou ativada (1).

select name, db_failover from sys.availability_groups

Exemplo de saída do dmv:

ErrorLog

O log de erros do SQL Server (ou o texto de sp_readerrorlog) mostrará a mensagem de erro 41653 quando um grupo de disponibilidade tiver passado por failover, devido às verificações de detecção de integridade em nível de banco de dados.

Por exemplo, esse trecho do log de erros mostra que uma gravação no log de transações falhou devido a um problema de disco e que, posteriormente, o banco de dados chamado AutoHa-Sample foi encerrado, o que fez com que a detecção de integridade no nível do banco de dados iniciasse o failover do grupo de disponibilidade.

2016-04-25 12:20:21.08 spid1s Erro: 17053, Severidade: 16, Estado: 1.

2016-04-25 12:20:21.08 spid1s SQLServerLogMgr::LogWriter: Erro do sistema operacional 21 (O dispositivo não está pronto.) encontrado. 2016-04-25 12:20:21.08 spid1s Erro de gravação durante a descarga do log.

2016-04-25 12:20:21.08 spid79 Erro: 9001, Gravidade: 21, Estado: 4.

2016-04-25 12:20:21.08 spid79 O log do banco de dados 'AutoHa-Sample' não está disponível. Verifique o log de eventos para obter as mensagens de erro relacionadas. Resolva todos os erros e reinicie o banco de dados.

2016-04-25 12:20:21.15 spid79 Erro: 41653, Severidade: 21, Estado: 1.

2016-04-25 12:20:21.15 spid79 O banco de dados "AutoHa-Sample" encontrou um erro (tipo de erro: 2 "DB_SHUTDOWN") causando falha no grupo de disponibilidade "Contoso-ag". Consulte o log de erros do SQL Server para obter informações sobre os erros encontrados. Se essa condição persistir, contate o administrador do sistema.

2016-04-25 12:20:21.17 spid79 Informações de estado do banco de dados 'AutoHa-Sample' - Hardened Lsn: '(34:664:1)' Commit LSN: '(34:656:1)' Hora da confirmação: 'Apr 25 2016 12:19PM'

2016-04-25 12:20:21.19 spid15s A conexão dos Grupos de Disponibilidade Always On com o banco de dados secundário foi encerrada para o banco de dados primário 'AutoHa-Sample' na réplica de disponibilidade 'SQLServer-0' com ID da réplica: {c4ad5ea4-8a99-41fa-893e-189154c24b49}. Essa mensagem é apenas informativa. Não é necessária nenhuma ação do usuário.

2016-04-25 12:20:21.21 spid75 Always On: A réplica local do grupo de disponibilidade "Contoso-ag" está se preparando para a transição para a função de resolução em resposta a uma solicitação do cluster WSFC (Cluster de Failover do Windows Server). Essa mensagem é apenas informativa. Não é necessária nenhuma ação do usuário.

2016-04-25 12:20:21.21 spid75 O estado da réplica de disponibilidade local no grupo de disponibilidade "ag" foi alterado de "PRIMARY_NORMAL" para "RESOLVING_NORMAL". O estado foi alterado porque o grupo de disponibilidade está ficando offline. A réplica está sendo colocada offline porque o grupo de disponibilidade associado foi excluído, porque o usuário colocou o grupo de disponibilidade associado offline no console de gerenciamento do WSFC (Clustering de Failover do Windows Server) ou porque o grupo de disponibilidade está fazendo failover para outra instância do SQL Server. Para obter mais informações, consulte o log de erros do SQL Server, o console de gerenciamento do Clustering de Failover do Windows Server (WSFC) ou o log do WSFC.

Evento Estendido sqlserver.availability_replica_database_fault_reporting

Há um novo Evento Estendido definido a partir do SQL Server 2016, que é acionado pela detecção de integridade em nível de banco de dados. O nome do evento é sqlserver.availability_replica_database_fault_reporting

Esse XEvent é disparado somente na réplica primária. Esse XEvent é disparado quando um problema de integridade no nível do banco de dados é detectado em um banco de dados hospedado em um grupo de disponibilidade.

Este é um exemplo para criar uma sessão de XEvent que captura esse evento. Como nenhum caminho é especificado, o arquivo de saída de XEvent deve estar localizado no caminho do log de erros padrão do SQL Server. Execute isso na réplica primária do seu grupo de disponibilidade:

Script de exemplo para a sessão de evento estendido

CREATE EVENT SESSION [AlwaysOn_dbfault] ON SERVER
ADD EVENT sqlserver.availability_replica_database_fault_reporting
ADD TARGET package0.event_file(SET filename=N'dbfault.xel',max_file_size=(5),max_rollover_files=(4))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,
    MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO
ALTER EVENT SESSION AlwaysOn_dbfault ON SERVER STATE=START
GO

Saída de evento estendido

Usando o SQL Server Management Studio, conecte-se ao SQL Server primário, expanda o nó Gerenciamento e, depois, expanda Eventos Estendidos. Localize a sessão (AlwaysOn_dbfault era o nome na amostra acima) e expanda-a para ver os arquivos de saída. Selecione o arquivo de saída e o arquivo de evento será aberto em uma nova guia.

Explicação sobre os campos:

Nesta saída de exemplo, o fault_type mostra que ocorreu um evento crítico no grupo de disponibilidade Contoso-ag, na réplica chamada SQLSERVER-1, devido ao banco de dados chamado AutoHa-Sample2, com o tipo de falha 2 – Desligamento.

Referências relacionadas

• CREATE AVAILABILITY GROUP

• ALTER AVAILABILITY GROUP

• Política de failover flexível para o failover automático de um grupo de disponibilidade (SQL Server)

• Melhorar a política de failover do Always On para testar unidades de dados e de log do Banco de Dados do SQL Server

• Eventos estendidos

• Como configurar um grupo de disponibilidade Always On para executar um failover quando o arquivo de dados do banco de dados não estiver disponível