Failover e Modos de Failover (Grupos de Disponibilidade Always On)

Aplica-se a:SQL Server

Este artigo descreve o failover e os modos de operação dos grupos de disponibilidade Always On do SQL Server.

Visão geral

No contexto de um grupo de disponibilidade, a função principal e a função secundária das réplicas de disponibilidade são normalmente intercambiáveis num processo conhecido como failover. Existem três formas de failover: failover automático (sem perda de dados), failover manual planejado (sem perda de dados) e failover manual forçado (com possível perda de dados), normalmente chamado de failover forçado . O failover automático e manual planejado preserva todos os seus dados. Um grupo de disponibilidade realiza failover no nível de réplica de disponibilidade. Ou seja, um grupo de disponibilidade faz failover para uma de suas réplicas secundárias (o destino de failover atual).

Durante o failover, o destino de failover assume a função principal, recupera seus bancos de dados e os coloca online como os novos bancos de dados primários. A réplica primária anterior, quando disponível, alterna para a função secundária e seus bancos de dados se tornam bancos de dados secundários. Potencialmente, essas funções podem alternar para frente e para trás (ou para um destino de failover diferente) em resposta a várias falhas ou para fins administrativos.

As formas de failover que uma determinada réplica de disponibilidade suporta são especificadas pela propriedade modo de failover. Para uma determinada réplica de disponibilidade, os possíveis modos de failover dependem do modo de disponibilidade da réplica, da seguinte maneira:

• As réplicas de confirmação síncrona suportam duas configurações: automática ou manual. A configuração "automática" suporta failover automático e failover manual. Para evitar a perda de dados, o failover automático e o failover planejado exigem que o destino de failover seja uma réplica secundária com confirmação síncrona e um estado de sincronização saudável (isso indica que cada banco de dados secundário no destino de failover está sincronizado com seu banco de dados primário correspondente). Sempre que uma réplica secundária não atende a essas duas condições, ela suporta apenas failover forçado. O failover forçado também é suportado em réplicas em um estado de RESOLVING.

• As réplicas de confirmação assíncrona suportam apenas o modo de failover manual. Além disso, como nunca são sincronizados, suportam apenas failover forçado.

Alterações do SQL Server 2025

O SQL Server 2025 introduz as seguintes alterações:

Failover rápido para problemas de saúde persistentes

Em um ambiente de grupo de disponibilidade Always On, o WSFC (Cluster de Failover do Windows) monitora a integridade do grupo de disponibilidade e suas réplicas. Quando um problema de saúde é identificado na réplica primária, o WSFC dispara uma sequência de ações corretivas. Por padrão, o WSFC reinicia o recurso do grupo de disponibilidade na réplica atual. Se o WSFC não puder colocar o recurso online novamente, o WSFC fará o failover do recurso do grupo de disponibilidade para outra réplica. Embora essa sequência de ações corretivas seja eficaz para falhas transitórias, ela pode potencialmente levar a atrasos no failover para falhas não transitórias.

O comportamento de failover do WSFC é controlado pelo valor RestartThreshold . Por padrão, RestartThreshold é definido como 1 para um grupo de disponibilidade Always On, o que significa que o WSFC tenta reiniciar o recurso no nó atual antes de fazer failover.

A partir do SQL Server 2025 (17.x), pode definir o RestartThreshold para um grupo de disponibilidade Always On para 0, o que indica ao WSFC que deve falhar o recurso do grupo de disponibilidade imediatamente quando um problema de integridade persistente for detetado. Isso é útil para cenários em que você deseja minimizar o tempo de inatividade e garantir que o grupo de disponibilidade esteja sempre disponível em uma réplica íntegra.

Há uma compensação óbvia:

• Ao definir RestartThreshold como 1, seu grupo de disponibilidade é mais tolerante a falhas transitórias e volta a ficar online mais rapidamente. No entanto, o failover e o tempo de inatividade podem ser mais longos para falhas persistentes.
• Ao definir RestartThreshold como 0, seu grupo de disponibilidade é menos tolerante a falhas transitórias, portanto, pode fazer failover desnecessariamente. No entanto, o failover e o tempo de inatividade podem ser menores para falhas persistentes.

Você pode usar o Gerenciador de Cluster de Failover ou o PowerShell para definir o recurso RestartThreshold para um grupo de disponibilidade Always On.

Por exemplo, para definir RestartThreshold para 0 no grupo de disponibilidade chamado ag1, use o seguinte comando:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Você pode verificar sua configuração atual RestartThreshold executando o seguinte comando:

Get-ClusterResource -Name "ag1" | Format-List *

Melhoria no envio de solicitações de página assíncronas

Quando um grupo de disponibilidade faz failover, cada réplica precisa encontrar um ponto de recuperação comum para sincronizar. O ponto de recuperação mantém o grupo de disponibilidade estável para que ele possa continuar a enviar alterações. Desfazer ou refazer faz parte deste processo de sincronização. O reverso do refazer acontece quando uma réplica secundária precisa reverter transações para atingir o ponto de recuperação comum. A reversão do refazer é mais comum durante a mudança de operação na recuperação de desastres (DR) para uma réplica assíncrona com FAILOVER_ALLOW_DATA_LOSS.

Em determinadas situações, com um failover de recuperação de desastres, à medida que a réplica secundária transita para primária, a nova primária sofre latência de rede da primária original (agora nova secundária), o que retarda o desfazer das operações de refazer no novo secundário.

Para melhorar o undo-of-redo neste cenário, o SQL Server 2025 (17.x) introduz uma atualização do mecanismo de sincronização, de modo que o grupo de disponibilidade agora executa pedidos de página de forma assíncrona e em lotes.

Considere o seguinte:

• A melhoria do mecanismo de sincronização está habilitada por padrão. Para desabilitar a melhoria e reverter para o comportamento padrão, habilite o sinalizador de rastreamento 12348 em todas as réplicas em um grupo de disponibilidade que são atualmente secundárias ou que podem ser secundárias no futuro.
• Se as réplicas de AG não tiverem latência de rede, esta melhoria pode não otimizar o processo de desfazer o refazer.

Os bancos de dados mudam para o estado de resolução após uma falha

Em casos raros, um ou mais bancos de dados de um grupo de disponibilidade podem permanecer em um estado Não sincronizando depois que um grupo de disponibilidade fica offline por um curto período de tempo devido a uma perda transitória de quorum do WSFC - como por desconexão temporária de rede ou a reinicialização da maioria dos nós de cluster. A atualização da lógica de recuperação do grupo de disponibilidade introduzida no SQL Server 2025 (17.x) melhora a tolerância interna a este tipo de perda de quórum de cluster e evita que as bases de dados dos grupos de disponibilidade fiquem presas no estado de Não Sincronização depois de o grupo de disponibilidade voltar a estar online.

Termos e Definições

Failover automático
Um failover que ocorre automaticamente na perda da réplica primária. O failover automático é suportado somente quando a réplica primária atual e uma réplica secundária estão configuradas com o modo de failover definido como AUTOMÁTICO e a réplica secundária atualmente sincronizada. Se o modo de failover da réplica primária ou secundária for MANUAL, o failover automático não poderá ocorrer.

Failover manual planejado (sem perda de dados)
O failover manual planejado, ou failover manual, é um failover iniciado por um administrador de banco de dados, normalmente, para fins administrativos. Um failover manual planejado só será suportado se a réplica primária e a réplica secundária estiverem configuradas para o modo de confirmação síncrona e se a réplica primária e a réplica secundária estiverem sincronizadas no momento (no estado SINCRONIZADO). Quando a réplica secundária de destino é sincronizada, o failover manual (sem perda de dados) é possível mesmo que a réplica primária tenha falhado porque os bancos de dados secundários estão prontos para failover. Um administrador de banco de dados inicia manualmente um failover manual.

Failover forçado (com possível perda de dados)
Um failover que pode ser iniciado por um administrador de bases de dados quando nenhuma réplica secundária está SINCRONIZADA com a réplica primária, ou a réplica primária não está a funcionar e nenhuma réplica secundária está pronta para o failover. O failover forçado corre o risco de possível perda de dados e é recomendado estritamente para recuperação de desastres. O failover forçado também é conhecido como failover manual forçado porque só pode ser iniciado manualmente. Esta é a única forma de failover suportada no modo de confirmação assíncrona de disponibilidade.

Configuração de comutação automática

Dentro de um determinado grupo de disponibilidade, um par de réplicas de disponibilidade (incluindo a réplica primária atual) configuradas para o modo de confirmação síncrona com failover automático, se houver. Uma configuração de failover automático entra em vigor apenas se a réplica secundária estiver atualmente SINCRONIZADA com a réplica primária.

Conjunto de failover de confirmação síncrona

Dentro de um determinado grupo de disponibilidade, um conjunto de duas ou três réplicas de disponibilidade (incluindo a réplica primária atual) configuradas para o modo de confirmação síncrona, se houver. Um conjunto de failover com confirmação síncrona só terá efeito se as réplicas secundárias estiverem configuradas para o modo de operação de failover manual e pelo menos uma réplica secundária estiver atualmente SINCRONIZADA com a réplica primária.

Todo o conjunto de failover

Dentro de um determinado grupo de disponibilidade, o conjunto de todas as réplicas de disponibilidade cujo estado operacional está atualmente ONLINE, independentemente do modo de disponibilidade e do modo de failover. A totalidade do conjunto de failover torna-se relevante quando nenhuma réplica secundária está atualmente sincronizada com a réplica primária.

Visão geral do failover

A tabela a seguir resume quais formas de failover são suportadas em diferentes modos de disponibilidade e failover. Para cada emparelhamento, o modo de disponibilidade efetivo e o modo de failover são determinados pela intersecção dos modos da réplica primária com os modos de uma ou mais réplicas secundárias.

¹ Se você emitir um comando de failover forçado em uma réplica secundária sincronizada, a réplica secundária se comportará da mesma forma que para um failover manual.

A quantidade de tempo que o banco de dados fica indisponível durante um failover depende do tipo de failover e de sua causa.

Conjuntos de Tolerância a Falhas

As formas de failover que são possíveis para um determinado grupo de disponibilidade podem ser entendidas em termos de conjuntos de failover. Um conjunto de failover consiste na réplica primária e nas réplicas secundárias que oferecem suporte a uma determinada forma de failover, da seguinte maneira:

• Conjunto de failover automático (opcional): Dentro de um determinado grupo de disponibilidade, um par de réplicas de disponibilidade (incluindo a réplica primária atual) configuradas para o modo de confirmação síncrona com failover automático, se houver. Uma configuração de failover automático entra em vigor apenas se a réplica secundária estiver atualmente SINCRONIZADA com a réplica primária.

• Conjunto de failover de confirmação síncrona (opcional): Dentro de um determinado grupo de disponibilidade, um conjunto de duas ou três réplicas de disponibilidade (incluindo a réplica primária atual) configuradas para o modo de confirmação síncrona, se houver. Um conjunto de failover com confirmação síncrona só terá efeito se as réplicas secundárias estiverem configuradas para o modo de operação de failover manual e pelo menos uma réplica secundária estiver atualmente SINCRONIZADA com a réplica primária.

• Todo o conjunto de failover : Dentro de um determinado grupo de disponibilidade, o conjunto de todas as réplicas de disponibilidade cujo estado operacional está atualmente ONLINE, independentemente do modo de disponibilidade e do modo de failover. A totalidade do conjunto de failover torna-se relevante quando nenhuma réplica secundária está atualmente sincronizada com a réplica primária.

Quando se configura uma réplica de disponibilidade como confirmação síncrona com tolerância a falhas automática, a réplica de disponibilidade torna-se parte do conjunto de tolerância a falhas automática. No entanto, se o conjunto entra em vigor depende da primária atual. As formas de failover que são realmente possíveis em um determinado momento dependem de quais conjuntos de failover estão atualmente em vigor.

Por exemplo, considere um grupo de disponibilidade que tenha quatro réplicas de disponibilidade, da seguinte maneira:

O comportamento de failover para cada réplica secundária depende de qual réplica de disponibilidade é atualmente a réplica primária. Basicamente, para uma determinada réplica secundária, o comportamento de failover é o pior caso, dada a réplica primária atual. A figura a seguir ilustra como o comportamento de failover de réplicas secundárias varia dependendo da réplica primária atual e se ela está configurada para o modo de confirmação assíncrona (com apenas failover forçado) ou o modo de confirmação síncrona (com ou sem failover automático).

Failover automático

Um failover automático faz com que uma réplica secundária qualificada faça a transição automática para a função principal depois que a réplica primária ficar indisponível. O failover automático é mais adequado quando o nó WSFC que hospeda a réplica primária está próximo do nó que hospeda a réplica secundária. Isso ocorre porque a sincronização de dados funciona melhor com baixa latência de mensagens entre computadores e porque as conexões de cliente podem permanecer locais.

Nesta secção:

• Condições necessárias para um failover automático

• Como funciona o failover automático

• Para habilitar o failover automático

Condições necessárias para um failover automático

O failover automático ocorre somente nas seguintes condições:

• Existe um conjunto de failover automático. Esse conjunto consiste em uma réplica primária e uma réplica secundária (o destino de failover automático) configuradas para o modo de confirmação síncrona e definidas como failover AUTOMÁTICO. Se a réplica primária estiver configurada para mudança manual, a mudança automática não poderá ocorrer, mesmo que uma réplica secundária esteja configurada para mudança automática.

  Para obter mais informações, consulte Modos de Disponibilidade (Grupos de Disponibilidade Always On).

• O destino de failover automático tem um estado de sincronização estável (isso indica que cada base de dados secundária no destino de failover está sincronizada com a respetiva base de dados primária).

  Sugestão

  Os Grupos de Disponibilidade Always On monitorizam a integridade de ambas as réplicas num conjunto de failover automático. Se uma das réplicas falhar, o estado de integridade do grupo de disponibilidade será definido como CRÍTICO. Se a réplica secundária falhar, o failover automático não será possível porque o destino de failover automático não está disponível. Se a réplica primária falhar, o grupo de disponibilidade fará failover para a réplica secundária. Até que a réplica primária original esteja online, não existe nenhum destino de failover automático. Em ambos os casos, para garantir a disponibilidade no caso improvável de uma falha sequencial, recomendamos que você configure uma réplica secundária diferente como o destino de failover automático.

  Para obter mais informações, consulte Utilizar políticas Always On para visualizar a integridade de um grupo de disponibilidade (SQL Server) e Alterar o modo de failover de uma réplica de disponibilidade (SQL Server).

• O cluster WSFC (Cluster de Failover do Windows Server) tem quórum. Para obter mais informações, consulte Modos de Quórum WSFC e Configuração de Votação (SQL Server).

• A réplica principal tornou-se indisponível e os níveis de condição de alternância definidos pela sua política de alternância flexível foram cumpridos. Para obter informações sobre os níveis de condições de failover, consulte Política de Failover Flexível para Failover Automático de um Grupo de Disponibilidade (SQL Server).

Como funciona o failover automático

Um failover automático inicia a seguinte sequência de ações:

1. Se a instância do servidor que está hospedando a réplica primária atual ainda estiver em execução, ela alterará o estado dos bancos de dados primários para DISCONNECTED e desconectará todos os clientes.

2. Se algum registro de log estiver aguardando em filas de recuperação na réplica secundária de destino, a réplica secundária aplicará os registros de log restantes para concluir a rolagem dos bancos de dados secundários.

   Observação

   A quantidade de tempo necessária para aplicar o log a um determinado banco de dados depende da velocidade do sistema, da carga de trabalho recente e da quantidade de log na fila de recuperação.

3. A réplica secundária anterior transita para a função principal. As suas bases de dados tornam-se as bases de dados primárias. A nova réplica primária reverte todas as transações pendentes (a fase de anulação da recuperação) o mais rapidamente possível. Os bloqueios isolam essas transações não confirmadas, permitindo que a reversão ocorra em segundo plano enquanto os clientes usam o banco de dados. Esse processo não reverte nenhuma transação confirmada.

   Até que um determinado banco de dados secundário seja conectado, ele é brevemente marcado como NOT_SYNCHRONIZED. Antes do início da recuperação de rollback, os bancos de dados secundários podem conectar-se aos novos bancos de dados primários e rapidamente passar para o estado SINCRONIZADO. O melhor cenário geralmente envolve uma terceira réplica com compromisso síncrono que permanece na função secundária após o failover.

4. Mais tarde, quando a instância do servidor que está hospedando a réplica primária anterior for reiniciada, ela reconhecerá que outra réplica de disponibilidade agora possui a função principal. A réplica primária anterior transita para a função secundária e seus bancos de dados se tornam bancos de dados secundários. A nova réplica secundária conecta-se à réplica primária atual e sincroniza o seu banco de dados com os bancos de dados da primária atual o mais rápido possível. Assim que a nova réplica secundária ressincronizar seus bancos de dados, o failover será novamente possível, na direção inversa.

Para configurar o failover automático

Uma réplica de disponibilidade pode ser configurada para suportar failover automático a qualquer momento.

Para configurar o failover automático

1. Verifique se a réplica secundária está configurada para usar o modo de disponibilidade de confirmação síncrona. Para obter mais informações, consulte Alterar o modo de disponibilidade de uma réplica de disponibilidade (SQL Server).

2. Defina o modo de failover como automático. Para obter mais informações, consulte Alterar o modo de failover de uma réplica de disponibilidade (SQL Server).

3. Opcionalmente, altere a política de failover flexível do grupo de disponibilidade para especificar os tipos de falhas que podem causar um failover automático. Para obter mais informações, consulte Configurar a Política de Failover Flexível para Controlar Condições de Failover Automático (Grupos de Disponibilidade Sempre Ativos) e Política de Failover para Instâncias de Cluster de Failover.

Failover manual planejado (sem perda de dados)

Um failover manual faz com que uma réplica secundária sincronizada faça a transição para a função principal depois que um administrador de banco de dados emite um comando de failover manual na instância do servidor que hospeda a réplica secundária de destino. Para oferecer suporte ao failover manual, a réplica secundária e a réplica primária atual devem ser configuradas para o modo de confirmação síncrona, caso esteja disponível. Cada banco de dados secundário na réplica de disponibilidade deve ser associado ao grupo de disponibilidade e sincronizado com seu banco de dados primário correspondente (ou seja, a réplica secundária deve ser sincronizada). Isso garante que todas as transações que foram confirmadas em um banco de dados primário anterior também foram confirmadas no novo banco de dados primário. Portanto, os novos bancos de dados primários são idênticos aos bancos de dados primários antigos.

A figura a seguir ilustra os estágios de um failover planejado:

1. Antes do failover, a réplica primária é hospedada pela instância do servidor no Node01.

2. Um administrador de banco de dados inicia um failover planejado. O destino de failover é a réplica de disponibilidade hospedada pela instância do servidor no Node02.

3. O alvo de failover (em Node02) torna-se a nova réplica primária. Como este é um failover planejado, a antiga réplica primária comuta para a função secundária durante o failover e coloca imediatamente os seus bancos de dados online como bancos de dados secundários.

Nesta secção:

• Condições requeridas para um failover manual

• Como funciona o failover manual

• Mantendo a disponibilidade durante as atualizações

Condições necessárias para um failover manual

Para suportar uma comutação por falha manual, a réplica primária atual deve estar configurada no modo de confirmação síncrona e uma réplica secundária deve ser:

• Configurado para o modo de confirmação síncrona.

• Atualmente sincronizado com a réplica primária.

Para fazer failover manualmente de um grupo de disponibilidade, você deve estar conectado à réplica secundária que se tornará a nova réplica primária.

Como funciona um failover manual planejado

Um failover manual planeado, que deve ser iniciado na réplica secundária alvo, dá início à seguinte sequência de ações:

1. Para garantir que nenhuma nova transação de usuário ocorra nos bancos de dados primários originais, o cluster WSFC envia uma solicitação à réplica primária para ficar offline.

2. Se algum log estiver aguardando na fila de recuperação de qualquer banco de dados secundário, a réplica secundária terminará de rolar para frente esse banco de dados secundário. A quantidade de tempo necessária depende da velocidade do sistema, da carga de trabalho recente e da quantidade de log na fila de recuperação. Para saber o tamanho atual da fila de recuperação, use o contador de desempenho da fila de recuperação . Para obter mais informações, consulte SQL Server, Réplica de banco de dados.

   Observação

   O tempo de failover pode ser regulado limitando o tamanho da fila de recuperação. No entanto, isso pode fazer com que a réplica primária fique mais lenta para permitir que a réplica secundária acompanhe.

3. A réplica secundária torna-se a nova réplica primária e a réplica primária anterior torna-se a nova réplica secundária.

4. A nova réplica primária reverte quaisquer transações não confirmadas e coloca seus bancos de dados online como os bancos de dados primários. Todos os bancos de dados secundários são marcados brevemente como NÃO SINCRONIZADOS até que se conectem e ressincronizem com os novos bancos de dados primários. Esse processo não reverte nenhuma transação confirmada.

5. Quando a réplica primária anterior volta a ficar online, ela assume a função secundária e o banco de dados primário anterior se torna o banco de dados secundário. A nova réplica secundária ressincroniza rapidamente os novos bancos de dados secundários com os bancos de dados primários correspondentes.

   Observação

   Assim que a nova réplica secundária ressincronizar os bancos de dados, será possível executar o failover novamente, mas na direção inversa.

Após o failover, os clientes devem se reconectar ao banco de dados primário atual. Para obter mais informações, consulte Escutadores de grupos de disponibilidade, conectividade do cliente e recuperação de aplicativos (SQL Server).

Mantendo a disponibilidade durante as atualizações

O administrador de banco de dados para seus grupos de disponibilidade pode usar failovers manuais para manter a disponibilidade do banco de dados quando você atualiza hardware ou software. Para usar um grupo de disponibilidade para atualizações de software, a instância do servidor e/ou o nó do computador que hospeda a réplica secundária alvo já devem ter recebido as atualizações. Para obter mais informações, consulte Atualizando instâncias de réplica do grupo de disponibilidade Always On.

Failover forçado (com possível perda de dados)

Forçar o failover de um grupo de disponibilidade (com possível perda de dados) é um método de recuperação de desastres que permite usar uma réplica secundária como um servidor em espera ativa. Como forçar o failover corre o risco de possível perda de dados, ele deve ser usado com cautela e moderação. Recomendamos forçar o failover somente se você precisar restaurar o serviço para seus bancos de dados de disponibilidade imediatamente e estiver disposto a correr o risco de perder dados. Para obter mais informações sobre os pré-requisitos e recomendações para forçar uma comutação e para um cenário de exemplo que utiliza uma comutação forçada para recuperar-se de uma falha catastrófica, consulte Executar uma Comutação Manual Forçada de um Grupo de Disponibilidade (SQL Server).

Nesta secção:

• Como funciona o failover forçado

• Riscos de forçar failover

• Por que o failover forçado é necessário após forçar o quórum

• Rastreando a perda potencial de dados

• Gerenciando a perda potencial de dados

Como funciona o failover forçado

Forçar o failover inicia uma transição da função principal para uma réplica de destino cuja função está no estado SECUNDÁRIO ou RESOLVENDO. O alvo de failover torna-se a nova réplica primária e imediatamente disponibiliza as suas cópias dos bancos de dados aos clientes. Quando a réplica primária anterior fica disponível, ela passa para a função secundária e seus bancos de dados se tornam bancos de dados secundários.

Todas as bases de dados secundárias (incluindo as antigas bases de dados primárias, quando estiverem disponíveis) são SUSPENSAS. Dependendo do estado de sincronização de dados anterior de um banco de dados secundário suspenso, ele pode ser adequado para salvar dados confirmados ausentes para esse banco de dados primário. Em uma réplica secundária configurada para acesso somente leitura, você pode consultar os bancos de dados secundários para descobrir manualmente os dados ausentes. Em seguida, você pode emitir instruções Transact-SQL nos novos bancos de dados primários para fazer as alterações necessárias.

Riscos de forçar a transição para o sistema de backup

É essencial entender que forçar o failover pode causar perda de dados. A perda de dados é possível porque a réplica de destino não pode se comunicar com a réplica primária e, portanto, não pode garantir que os bancos de dados estejam sincronizados. Forçar o failover inicia uma nova bifurcação de recuperação. Como os bancos de dados primários originais e os bancos de dados secundários estão em bifurcações de recuperação diferentes, cada um deles agora contém dados que o outro não contém: cada banco de dados primário original contém as alterações que ainda não foram enviadas da sua fila de envio para o banco de dados secundário anterior (o registo de alterações não enviadas); os bancos de dados secundários anteriores contêm quaisquer alterações que ocorram após a obrigatoriedade do failover.

Se o failover for forçado porque a réplica primária falhou, a perda potencial de dados dependerá de se algum log de transação foi enviado para a réplica secundária antes da falha. No modo de confirmação assíncrona, o log acumulado não enviado é sempre uma possibilidade. No modo de confirmação síncrona, isso só é possível até que os bancos de dados secundários sejam sincronizados.

A tabela a seguir resume a possibilidade de perda de dados para um determinado banco de dados na réplica para a qual você força o failover.

Os bancos de dados secundários rastreiam apenas duas bifurcações de recuperação, portanto, se você executar vários failovers forçados, qualquer banco de dados secundário que tenha iniciado a sincronização de dados com o failover de força anterior pode não conseguir retomar. Se isso ocorrer, os bancos de dados secundários que não puderem ser retomados precisarão ser removidos do grupo de disponibilidade, restaurados para o point-in-time correto e reingressados no grupo de disponibilidade. Erro 1408 com estado 103 pode ser observado neste cenário (Erro: 1408, gravidade: 16, estado: 103). Uma restauração não funcionará em várias bifurcações de recuperação, portanto, certifique-se de executar um backup de log depois de executar mais de um failover forçado.

Por que o failover forçado é necessário após forçar o quórum

Depois que o quórum é forçado no cluster WSFC (quórum forçado), você precisa executar um failover forçado (com possível perda de dados) em cada grupo de disponibilidade. O processo de transferência forçado é necessário porque o estado efetivo dos valores do cluster WSFC pode ter sido perdido. A prevenção de failovers normais após um quórum forçado é necessária devido à possibilidade de que uma réplica secundária não sincronizada pareça estar sincronizada no cluster WSFC reconfigurado.

Por exemplo, considere um cluster WSFC que hospeda um grupo de disponibilidade em três nós: o Nó A hospeda a réplica primária e o Nó B e o Nó C hospedam uma réplica secundária. O nó C é desligado do cluster WSFC enquanto a réplica secundária local está sincronizada. Mas o Nó A e o Nó B mantêm um quórum saudável e o grupo de disponibilidade permanece ativo. No Nó A, a réplica primária continua a aceitar atualizações e, no Nó B, a réplica secundária continua a ser sincronizada com a réplica primária. A réplica secundária no Nó C torna-se dessincronizada e fica cada vez mais atrás da réplica primária. No entanto, como o nó C está desconectado, a réplica permanece, incorretamente, no estado SINCRONIZADO.

Se o quórum for perdido e, em seguida, for forçado no Nó A, o estado de sincronização do grupo de disponibilidade no cluster WSFC deverá estar correto, com a réplica secundária no Nó C mostrada como UNSYNCHRONIZED. No entanto, se o quórum for imposto no Nó C, a sincronização do grupo de disponibilidade estará incorreta. O estado de sincronização no cluster terá sido revertido para o estado em que estava quando o Nó C foi desconectado, com a réplica secundária no Nó C mostrada incorrectamente como SINCRONIZADA. Como os failovers manuais planejados garantem a segurança dos dados, eles não podem colocar um grupo de disponibilidade online novamente após o quórum ser forçado.

Rastreando a perda potencial de dados

Quando o cluster WSFC tem um quórum íntegro, você pode estimar o potencial atual de perda de dados em bancos de dados. Para uma determinada réplica secundária, o potencial atual de perda de dados depende de quão longe os bancos de dados secundários locais estão atrasados em relação aos bancos de dados primários correspondentes. Como a quantidade de atraso varia ao longo do tempo, recomendamos que você acompanhe periodicamente a perda potencial de dados para seus bancos de dados secundários não sincronizados. O atraso de seguimento envolve comparar o LSN da Última Confirmação e o Tempo da Última Confirmação para cada banco de dados primário e seus bancos de dados secundários, conforme segue:

1. Conecte-se à réplica principal.

2. Consulte as colunas last_commit_lsn (LSN da última transação confirmada) e last_commit_time (hora da última confirmação) da sys.dm_hadr_database_replica_states exibição de gerenciamento dinâmico.

3. Compare os valores retornados para cada banco de dados primário e cada um de seus bancos de dados secundários. A diferença entre os LSNs da última confirmação deles indica a quantidade de atraso.

4. Você pode disparar um alerta quando a quantidade de atraso em um banco de dados ou conjunto de bancos de dados exceder o atraso máximo desejado por um determinado período de tempo. Por exemplo, a consulta pode ser executada por um trabalho que é executado a cada minuto em cada banco de dados primário. Se a diferença entre o last_commit_time de um banco de dados primário e qualquer um de seus bancos de dados secundários tiver excedido o RPO (Recovery Point Objetive, objetivo de ponto de recuperação) (por exemplo, 5 minutos) desde a última vez que o trabalho foi executado, o trabalho poderá gerar um alerta.

Gerenciando a perda potencial de dados

Após o failover ter sido forçado, todos os bancos de dados secundários são suspensos. Isso inclui os bancos de dados primários anteriores, depois que a réplica primária anterior volta online e descobre que agora é uma réplica secundária. Você deve retomar manualmente cada banco de dados suspenso individualmente em cada réplica secundária.

Quando a réplica primária anterior estiver disponível, supondo que seus bancos de dados não estejam danificados, você poderá tentar gerenciar a perda potencial de dados. A abordagem disponível para gerenciar a perda potencial de dados depende se a réplica primária original se conectou à nova réplica primária. Supondo que a réplica primária original possa acessar a nova instância primária, a reconexão ocorre de forma automática e transparente.

A réplica primária original foi reconectada

Normalmente, após uma falha, quando a réplica primária original é reiniciada, ela se reconecta rapidamente ao parceiro. Ao se reconectar, a réplica primária original se torna a réplica secundária. Suas bases de dados tornam-se bases de dados secundárias e entram no estado SUSPENSO. Os novos bancos de dados secundários não serão revertidos, a menos que você os retome.

No entanto, os bancos de dados suspensos são inacessíveis, portanto, você não pode inspecioná-los para avaliar quais dados seriam perdidos se você retomasse um determinado banco de dados. Portanto, a decisão de retomar ou remover um banco de dados secundário depende se você está disposto a aceitar qualquer perda de dados, da seguinte maneira:

• Se perder quaisquer dados for inaceitável, você deve remover os bancos de dados do grupo de disponibilidade para salvá-los.

  O administrador do banco de dados agora pode recuperar os bancos de dados primários anteriores e tentar recuperar os dados que teriam sido perdidos. No entanto, quando um banco de dados primário anterior fica online, ele é divergente do banco de dados primário atual, portanto, o administrador do banco de dados precisa tornar o banco de dados removido ou o banco de dados primário atual inacessível aos clientes para evitar mais divergências dos bancos de dados e evitar problemas de failover do cliente.

• Se a perda de dados for aceitável para suas metas de negócios, você poderá retomar os bancos de dados secundários.

  Iniciar um novo banco de dados secundário faz com que ele seja retrocedido como a primeira etapa na sincronização do banco de dados. Se algum registro de log estava aguardando na fila de envio no momento da falha, as transações correspondentes serão perdidas, mesmo que tenham sido confirmadas.

A réplica primária original não foi reconectada

Se você puder impedir temporariamente que a réplica primária original se reconecte pela rede à nova réplica primária, poderá inspecionar os bancos de dados primários originais para avaliar quais dados seriam perdidos se fossem retomados.

• Se a possível perda de dados for aceitável

  Permita que a réplica primária original se reconecte à nova réplica primária. A reconexão faz com que os novos bancos de dados secundários sejam suspensos. Para iniciar a sincronização de dados em um banco de dados, basta retomá-la. A nova réplica secundária elimina o ponto de recuperação original para aquele banco de dados, perdendo quaisquer transações que nunca foram enviadas ou recebidas pela réplica secundária prévia.

• Se a perda de dados for inaceitável

  Se o banco de dados primário original contiver dados críticos que seriam perdidos se você retomasse o banco de dados suspenso, você poderá preservar os dados no banco de dados primário original removendo-os do grupo de disponibilidade. Isso faz com que o banco de dados entre no estado RESTORING. Neste ponto, recomendamos que você tente fazer backup da parte final do log do banco de dados removido. Em seguida, você pode atualizar o primário atual (o antigo banco de dados secundário) exportando os dados que deseja salvar do banco de dados primário original e importando-os para o banco de dados primário atual. Recomendamos fazer um backup completo do banco de dados primário atualizado o mais rápido possível.

  Em seguida, na instância do servidor que hospeda a nova réplica secundária, você pode excluir o banco de dados secundário suspenso e criar um novo banco de dados secundário restaurando esse backup (e pelo menos um backup de log subsequente) usando RESTORE WITH NORECOVERY. Recomendamos adiar backups de log adicionais dos bancos de dados primários atuais até que os bancos de dados secundários correspondentes sejam retomados.

Conteúdo relacionado

• Visão geral dos grupos de disponibilidade Always On (SQL Server)
• Modos de Disponibilidade (Grupos de Disponibilidade Always On)
• Windows Server Failover Clustering (WSFC) com SQL Server
• Transações entre bancos de dados e transações distribuídas para grupos de disponibilidade Always On e espelhamento de banco de dados (SQL Server)
• Política de failover para instâncias de cluster de failover
• Política de failover flexível para failover automático de um grupo de disponibilidade (SQL Server)

Tarefas relacionadas

Configurar o comportamento de failover

• alterar o modo de disponibilidade de uma réplica de disponibilidade (SQL Server)
• Alterar o modo de failover de uma réplica de disponibilidade (SQL Server)
• Configurar a Política de Failover Flexível para Controlar as Condições de Failover Automático (Grupos de Disponibilidade Always On)

Executar um failover manual

• Executar um failover manual planeado de um grupo de disponibilidade (SQL Server)
• Executar um Failover Manual Forçado de um Grupo de Disponibilidade (SQL Server)
• Usar o Assistente para Grupo de Disponibilidade de Failover (SQL Server Management Studio)
• Gestão de entradas e tarefas para os bancos de dados de um grupo de disponibilidade (SQL Server)

Configurar a Configuração do Quórum WSFC

• Configurar definições de Peso do Nodo do Quórum do Cluster
• Exibir configurações de peso do nó do quórum do cluster
• Forçar um Cluster WSFC a Iniciar Sem Quórum