Failover e modos de failover (Grupos de Disponibilidade AlwaysOn)

Aplica-se:SQL Server

Este artigo descreve a conmutação por falha e os modos de grupos de disponibilidade Always On do SQL Server.

Visão geral

Dentro do contexto de um grupo de disponibilidade, as funções primária e secundária das réplicas de disponibilidade, normalmente, são intercambiáveis em um 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), geralmente chamado de failover forçado. Tanto o failover automático quanto o failover manual planejado preservam todos os seus dados. Um grupo de disponibilidade faz failover no nível da réplica de disponibilidade. Ou seja, um grupo de disponibilidade realiza failover em uma de suas réplicas secundárias (o destino de failoveratual).

Durante o failover, o destino de failover assume a função primária, 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 ser alternadas (ou usar um destino de failover diferente) como resposta a várias falhas ou por razões administrativas.

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 modos de failover possíveis dependem do modo de disponibilidade da réplica, da seguinte maneira:

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

• Réplicas de confirmação assíncrona dão suporte somente ao modo de failover manual. Além disso, como eles nunca são sincronizados, eles dão suporte apenas ao failover forçado.

Alterações do SQL Server 2025

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

Failover rápido para problemas persistentes de saúde

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 é detectado 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 novamente online, o WSFC falhará no 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), você pode definir o parâmetro RestartThreshold do grupo de disponibilidade Always On como 0, o que informa ao WSFC para realizar o failover do recurso do grupo de disponibilidade imediatamente quando um problema de integridade persistente for detectado. 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 mais curtos para falhas persistentes.

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

Por exemplo, para definir o RestartThreshold como 0 para o 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 gerenciamento de solicitações de páginas 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 e refazer são parte deste processo de sincronização. Desfazer da repetição acontece quando uma réplica secundária deve reverter transações para chegar ao ponto de recuperação comum. Desfazer-de-refazer é mais comum durante o failover de recuperação de desastre (DR) para uma réplica assíncrona com FAILOVER_ALLOW_DATA_LOSS.

Em determinadas situações, com um failover de DR, quando a réplica secundária se transforma em primária, o novo primário enfrenta latência de rede do primário original (agora novo secundário), o que retarda o processo de desfazer o refazer no novo secundário.

Para melhorar a reversão da reexecução para esse cenário, o SQL Server 2025 (17.x) apresenta uma atualização no mecanismo de sincronização, possibilitando que o grupo de disponibilidade execute solicitações de página assíncronamente e em lotes.

Considere o seguinte:

• O aprimoramento do mecanismo de sincronização é habilitado 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 atualmente são secundários ou que podem ser secundários no futuro.
• Se as réplicas de AG não tiverem latência de rede, essa melhoria pode não melhorar o processo de desfazer refazimento.

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 WSFC, como a desconexão temporária de rede ou quando a maioria dos nós do cluster reinicia. A atualização para a lógica de recuperação do grupo de disponibilidade introduzida no SQL Server 2025 (17.x) aprimora a tolerância interna a esse tipo de perda de quorum de cluster e impede que os bancos de dados do grupo de disponibilidade fiquem presos no estado Não Sincronização depois que o grupo de disponibilidade voltar a ficar online novamente.

Termos e definições

failover automático
Um failover que ocorre automaticamente na perda da réplica primária. Há suporte para o failover automático apenas quando a réplica primária atual e uma réplica secundária estão configuradas como modo de failover definido como AUTOMATIC e a réplica secundária está sincronizada no momento. 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, em geral para fins administrativos. Um failover manual planejado tem suporte apenas quando a réplica primária e a réplica secundária estão configuradas para o modo de confirmação síncrona, e a réplica primária e a secundária estão sincronizadas no momento (no modo SYNCHRONIZED). Quando a réplica secundária de destino está sincronizada, o failover manual (sem perda de dados) será possível até mesmo se a réplica primária tiver falhado, pois os bancos de dados secundários estão prontos para o failover. Um administrador de banco de dados inicia um failover manual manualmente.

Failover forçado (com possível perda de dados)
Um failover que pode ser iniciado por um administrador de banco 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á operando e nenhuma réplica secundária está pronta para o failover. O failover forçado leva a um risco de perda de dados e é recomendável estritamente para a recuperação de desastres. O failover forçado também é conhecido como failover manual forçado porque ele só pode ser iniciado manualmente. Este é o único formulário de failover com suporte em modo de disponibilidade da confirmação assíncrona.

conjunto de failover automático

Em um grupo de disponibilidade específico, existe apenas um par de réplicas de disponibilidade (inclusive a réplica primária atual) que está configurado para o modo de confirmação síncrona com failover automático, se houver. Um conjunto de failover automático terá efeito apenas se a réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

conjunto de failover de confirmação síncrona

Em um grupo de disponibilidade específico, um conjunto de duas ou três réplicas de disponibilidade (inclusive a réplica primária atual) que estão configuradas para o modo de confirmação síncrona, se houver. Um conjunto de failover de confirmação síncrona terá efeito se as réplicas secundárias estiverem configuradas para o modo de failover manual e pelo menos uma réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

conjunto de failover inteiro

Dentro de um determinado grupo de disponibilidade, o conjunto de todas as réplicas de disponibilidade cujo estado operacional é ONLINE no momento, independentemente do modo de disponibilidade e do modo de failover. O conjunto de failover inteiro se tornará relevante quando nenhuma réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

Visão geral de failover

A tabela a seguir resume os formulários de failover com suporte sob diferentes modos de disponibilidade e failover. Para cada emparelhamento, o modo de disponibilidade efetivo e o modo de failover são determinados pela interseção dos modos da réplica primária mais 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 durante o qual o banco de dados fica indisponível durante um failover depende do tipo de failover e de sua causa.

Conjuntos de failover

As formas de failover possíveis para um determinado grupo de disponibilidade podem ser compreendidas 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): Em um grupo de disponibilidade específico, existe apenas um par de réplicas de disponibilidade (inclusive a réplica primária atual) que está configurado para o modo de confirmação síncrona com failover automático, se houver. Um conjunto de failover automático terá efeito apenas se a réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

• conjunto de failover de confirmação síncrona (opcional): Em um grupo de disponibilidade específico, um conjunto de duas ou três réplicas de disponibilidade (inclusive a réplica primária atual) que estão configuradas para o modo de confirmação síncrona, se houver. Um conjunto de failover de confirmação síncrona terá efeito se as réplicas secundárias estiverem configuradas para o modo de failover manual e pelo menos uma réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

• Conjunto de failover inteiro: Dentro de um determinado grupo de disponibilidade, o conjunto de todas as réplicas de disponibilidade cujo estado operacional é ONLINE no momento, independentemente do modo de disponibilidade e do modo de failover. O conjunto de failover inteiro se tornará relevante quando nenhuma réplica secundária estiver SYNCHRONIZED no momento com a réplica primária.

Quando você configura uma réplica de disponibilidade como confirmação síncrona com failover automático, a réplica de disponibilidade se torna parte do conjunto de failover automático. Porém, se a definição entra em vigor ou não depende da primária atual. Os formulários de failover que são realmente possíveis em um determinado momento dependem de quais conjuntos de failover estão em vigor atualmente.

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

O comportamento do failover para cada réplica secundária depende de qual réplica de disponibilidade é a réplica primária no momento. Basicamente, para uma determinada réplica secundária, o comportamento de failover é o pior caso dependendo da 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 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 primária depois que a réplica primária se torna indisponível. O failover automático é mais adequado quando o nó WSFC que hospeda a réplica primária é local em relação ao nó que hospeda a réplica secundária. Isso ocorre porque a sincronização de dados funciona melhor com baixa latência de mensagem entre computadores e porque as conexões cliente podem permanecer locais.

Nesta seção:

• Condições exigidas para um failover automático

• Como o failover automático funciona

• Para habilitar o failover automático

Condições exigidas para um failover automático

O failover automático ocorre apenas sob as seguintes condições:

• Um conjunto de failover automático existe. Este conjunto consiste em uma réplica primária e uma réplica secundária (o destino do failover automático) que estão configuradas para modo de confirmação síncrona e ambas estão definidas como failover AUTOMATIC. Se a réplica primária estiver configurada para failover MANUAL, o failover AUTOMÁTICO não poderá ocorrer, mesmo que uma réplica secundária esteja configurada para failover AUTOMÁTICO.

  Para obter mais informações, confira Modos de Disponibilidade (Grupos de Disponibilidade AlwaysOn).

• O destino do failover automático tem um estado de sincronização íntegro (isto indica que todo banco de dados secundário no destino de failover é sincronizado com seu banco de dados primário correspondente).

  Dica

  Os Grupos de Disponibilidade AlwaysOn monitoram a integridade das duas réplicas em um conjunto de failover automático. Se alguma réplica falhar, o estado de integridade do grupo de disponibilidade será definido como CRITICAL. Se a réplica secundária falhar, a alternância automática não será possível porque o alvo da alternância automática não está disponível. Se a réplica primária falhar, o grupo de disponibilidade realizará failover para a réplica secundária. Até que a réplica primária antiga fique online, nenhum destino de failover automático existirá. Em qualquer caso, 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, confiraUsar as Políticas AlwaysOn para Exibir 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 do WSFC (Windows Server Failover Clustering) tem quorum. Para saber mais, consulte Configuração de modos de quorum WSFC e votação (SQL Server).

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

Como o failover automático funciona

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 qualquer registro de log estiver esperando 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 o roll forward dos bancos de dados secundários.

   Observação

   A quantidade de tempo exigida 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 antiga faz a transição para a função primária. Seus bancos de dados se tornam os bancos de dados primários. A nova réplica primária reverte todas as transações não confirmadas (a fase desfazer da recuperação) o mais rapidamente possível. 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 esteja conectado, ele será marcado brevemente como NOT_SYNCHRONIZED. Antes do início da recuperação da reversão, os bancos de dados secundários podem se conectar aos novos bancos de dados primários e fazer a transição rápida para o estado SYNCHRONIZED. O melhor caso geralmente é aquele em que uma terceira réplica de confirmação síncrona permanece na função secundária após o failover.

4. Posteriormente, quando a instância de servidor que está hospedando a réplica primária antiga é reiniciada, ela reconhece que outra réplica de disponibilidade possui a função primária agora. A réplica primária antiga faz a transição 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 atualiza seu banco de dados com os bancos de dados primários atuais o mais rapidamente possível. Assim que a nova réplica secundária tiver sincronizado seus bancos de dados novamente, o failover será possível, na direção reversa.

Para configurar o failover automático

Uma réplica de disponibilidade pode ser configurada para dar suporte a 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, confira Alterar o Modo de Disponibilidade de uma Réplica de Disponibilidade (SQL Server).

2. Defina o modo do failover como automático. Para obter mais informações, confira 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 as classificações de falhas que podem causar um failover automático. Para obter mais informações, confira Configurar a Política de Failover Flexível para Controlar Condições de Failover Automático (Grupos de disponibilidade AlwaysOn) 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 primária 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 dar 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, se houver. Todo banco de dados secundário na réplica de disponibilidade deve ser unido 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 confirmadas em um banco de dados primário antigo 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 de servidor em 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 de servidor em Node02.

3. O destino de failover (em Node02) se torna a nova réplica primária. Como esse é um failover planejado, a réplica primária anterior alterna para a função secundária durante o failover e coloca seus bancos de dados online como bancos de dados secundários imediatamente.

Nesta seção:

• Condições exigidas para um failover manual

• Como o failover manual funciona

• Mantendo a disponibilidade durante as atualizações

Condições exigidas para um failover manual

Para dar suporte a um failover manual, a réplica primária atual deve ser definida como modo de confirmação síncrona e uma réplica secundária deve ser:

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

• Sincronizada atualmente com a réplica primária.

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

Como o failover manual planejado funciona

O failover manual planejado, que deve ser iniciado na réplica secundária de destino, inicia a 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 do WSFC envia uma solicitação à réplica primária para tornar-se offline.

2. Se algum log estiver esperando na fila de recuperação de qualquer banco de dados secundário, a réplica secundária concluirá o roll forward daquele 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 Recovery Queue . Para obter mais informações, consulte SQL Server, Réplica de Banco de Dados.

   Observação

   O tempo do failover pode ser controlado por meio da limitação do tamanho da fila de recuperação. Porém, isso pode fazer com que a réplica primária se torne mais lenta para permitir que a réplica secundária acompanhe.

3. A réplica secundária se torna a nova réplica primária, e a réplica secundária antiga se torna a nova réplica secundária.

4. A nova réplica primária reverte todas as transações não confirmadas e torna seus bancos de dados disponíveis online como primários. Todos os bancos de dados secundários são marcados brevemente como NOT SYNCHRONIZED 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 antiga volta a ficar online, ela assume a função secundária, e o banco de dados primário antigo 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 tiver sincronizado os bancos de dados novamente, o failover será possível, mas na direção reversa.

Após o failover, os clientes devem se reconectar ao banco de dados primário atual. Para obter mais informações, confira Ouvintes do Grupo de Disponibilidade, Conectividade de Cliente e Failover de Aplicativo (SQL Server).

Mantendo a disponibilidade durante as atualizações

O administrador de banco de dados de seus grupos de disponibilidade pode usar failovers manuais para manter a disponibilidade dos bancos de dados quando você atualizar 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 de destino já deverá ter recebido as atualizações. Para obter mais informações, consulte Atualizar instâncias de réplica do Grupo de Disponibilidade AlwaysOn.

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 desastre que permite usar uma réplica secundária como um servidor em espera quente. Como forçar o failover corre o risco de possível perda de dados, ele deve ser usado com cuidado e moderação. É recomendável forçar o failover apenas se você precisar restaurar serviço para seus bancos de dados de disponibilidade imediatamente e estiver disposto a perder dados. Para obter mais informações sobre os pré-requisitos e as recomendações para forçar failover e para obter um cenário de exemplo que usa um failover forçado para se recuperar de uma falha catastrófica, confira Executar um Failover Manual Forçado de um Grupo de Disponibilidade (SQL Server).

Nesta seção:

• Como o failover forçado funciona

• Riscos de forçar o failover

• Por que o failover forçado é necessário após um quorum forçado

• Controlando a potencial perda de dados

• Gerenciando a perda potencial de dados

Como o failover forçado funciona

Um failover forçado inicia uma transição da função primária para uma réplica de destino cujo estado da função é SECONDARY ou RESOLVING. O destino do failover se torna a nova réplica primária e logo oferece suas cópias dos bancos de dados para clientes. Quando a réplica primária anterior fica disponível, ela faz a transição para a função secundária e seus bancos de dados se tornam bancos de dados secundários.

Todos os bancos de dados secundários (inclusive os bancos de dados primários antigos, quando ficam disponíveis) são SUSPENDED. Dependendo do estado de sincronização de dados anterior de um banco de dados secundário suspenso, ele poderá 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 dados ausentes. Você pode emitir instruções Transact-SQL para fazer as alterações necessárias nos novos bancos de dados primários.

Riscos de forçar o failover

É 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 sejam sincronizados. O forçamento do failover inicia uma 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 banco de dados não contém: cada banco de dados primário original contém quaisquer alterações que ainda não foram enviadas de sua fila de envio para o banco de dados secundário anterior (o log não enviado); os bancos de dados secundários anteriores contêm quaisquer alterações que ocorram depois que o failover foi forçado.

Se o failover for forçado porque a réplica primária falhou, a possível perda de dados dependerá se os logs de transações foram enviados ou não 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íncrono, isso é possível apenas até que os bancos de dados secundários sejam sincronizados.

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

Os bancos de dados secundários acompanham apenas duas bifurcações de recuperação, portanto, se você executar vários failovers forçados, nenhum banco de dados secundário que iniciou a sincronização de dados com o failover forçado anterior poderá ser retomado. Se isso ocorrer, todos os bancos de dados secundários que não puderem ser retomados precisarão ser removidos do grupo de disponibilidade, restaurados para o ponto correto no tempo e retornados ao grupo de disponibilidade. O erro 1408 com o 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 do log depois de executar mais de um failover forçado.

Por que o failover forçado é necessário após um quorum forçado

Depois que o quorum for forçado no cluster WSFC, será necessário realizar um failover forçado (com possível perda de dados) em cada grupo de disponibilidade. O failover forçado é necessário porque o estado real dos valores do cluster WSFC pode ter sido perdido. É necessário evitar failovers normais após um quorum forçado devido à possibilidade de uma réplica secundária não sincronizada parecer 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, enquanto os nós B e C hospedam, cada um, uma réplica secundária. O nó C é desconectado do cluster WSFC enquanto a réplica secundária local é SYNCHRONIZED. Mas os nós A e B retêm um quorum íntegro e o grupo de disponibilidade permanece online. No nó A, a réplica primária continua a aceitar atualizações e, no nó B, a réplica secundária continua a sincronizar com a réplica primária. A réplica secundária no nó C se torna não sincronizada e fica bem atrás da réplica primária. Entretanto, como o nó C é desconectado, a réplica permanece, incorretamente, no estado SYNCHRONIZED.

Se o quorum for perdido e, em seguida, 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 quorum for forçado no nó C, a sincronização do grupo de disponibilidade estará incorreta. A sincronização no cluster será revertida ao estado de quando o Nó C foi desconectado, ou seja, com a réplica secundária no Nó C mostrada incorretamente como SYNCHRONIZED. Como os failovers manuais planejados garantem a segurança dos dados, eles não são permitidos para colocar um grupo de disponibilidade online novamente depois que o quorum for forçado.

Controlando a potencial perda de dados

Quando o cluster WSFC tem um quorum íntegro, você pode calcular o potencial atual de perda de dados em bancos de dados. Para uma réplica secundária específica, o potencial atual de perda de dados depende do atraso dos bancos de dados secundários locais em relação aos bancos de dados primários correspondentes. Como o tempo de retardo varia com o passar do tempo, é recomendável acompanhar periodicamente a possível perda de dados para os bancos de dados secundários não sincronizados. Controlar o retardo envolve comparar a LSN da Última Confirmação e a Hora da Última Confirmação para cada banco de dados primário e seus bancos de dados secundários, como segue:

1. Conecte-se à réplica primária.

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

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 LSNs da Última Confirmação indica o tempo de retardo.

4. Você pode disparar um alerta quando o tempo de retardo em um banco de dados ou conjunto de bancos de dados excede o retardo máximo desejado para um período de tempo específico. Por exemplo, a consulta pode ser executada por um trabalho 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 exceder o objetivo de ponto de recuperação ou RPO (por exemplo, 5 minutos) desde a última execução do trabalho, esse trabalho poderá gerar um alerta.

Gerenciando a perda potencial de dados

Após um failover forçado, todos os bancos de dados secundários são suspensos. Isso inclui os antigos bancos de dados primários, depois que a antiga réplica primária voltar a ficar online e descobrir que agora é uma réplica secundária. É necessário retomar manualmente cada banco de dados suspenso individualmente em cada réplica secundária.

Assim que a réplica primária antiga estiver disponível, supondo que seus bancos de dados não estejam danificados, você poderá tentar gerenciar a possível perda de dados. A abordagem disponível para o gerenciamento da perda potencial de dados depende de se a réplica primária original conectou-se com a nova réplica primária. Presumindo que a réplica primária original pode acessar a nova instância primária, a reconexão ocorrerá de forma automática e transparente.

A réplica primária original foi reconectada

Normalmente, depois de uma falha, quando a réplica primária original é reiniciada, ela se reconecta rapidamente a sua parceira. Na reconexão, a réplica primária original se torna a réplica secundária. Seus bancos de dados se tornam os bancos de dados secundários e entram no estado SUSPENDED. 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 estã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 a perda dos dados for inaceitável, será necessário remover os bancos de dados do grupo de disponibilidade para resgatá-los.

  O administrador de banco de dados agora pode recuperar os bancos de dados primários antigos e tentar recuperar os dados que foram 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.

  A retomada de um novo banco de dados secundário faz com que ele seja revertido como a primeira etapa na sincronização do banco de dados. Se houver registros de log aguardando na fila de envio no momento da falha, as transações correspondentes serão perdidas, mesmo se tiverem sido confirmadas.

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

Se for possível impedir temporariamente que a réplica primária original seja reconectada na rede com a nova réplica primária, você poderá inspecionar os bancos de dados primários originais para avaliar os dados que seriam perdidos se eles fossem retomados.

• Se a perda potencial 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á-lo. A nova réplica secundária cancela a bifurcação de recuperação original para aquele banco de dados, perdendo as transações que nunca foram enviadas ou recebidas pela réplica secundária antiga.

• 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-o do grupo de disponibilidade. Isso faz com que o banco de dados entre no estado RESTORING. Nesse ponto, é recomendável tentar fazer backup da parte final do log do banco de dados removido. Em seguida, é possível atualizar o primário atual (o banco de dados secundário antigo) exportando os dados que você deseja resgatar do banco de dados primário original e importando-os no banco de dados primário atual. É recomendável fazer um backup completo dos bancos de dados primários atualizados o mais rápido possível.

  Em seguida, na instância de 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. É recomendável atrasar 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 AlwaysOn (SQL Server)
• Modos de disponibilidade (grupos de disponibilidade AlwaysOn)
• WSFC (Windows Server Failover Clustering) com o SQL Server
• Transações entre bancos de dados e transações distribuídas para Grupos de Disponibilidade AlwaysOn e o 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 condições de failover automático (grupos de disponibilidade AlwaysOn)

Executar um failover manual

• Executar um failover manual planejado 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)
• Gerenciamento de logons e trabalhos para os bancos de dados de um grupo de disponibilidade (SQL Server)

Configurar a configuração de quorum do WSFC

• Definir configurações de NodeWeight de quorum do cluster
• Exibir configurações de NodeWeight de quorum do cluster
• Forçar um cluster WSFC para iniciar sem um quorum