Executar um failover manual forçado de um grupo de disponibilidade Always On (SQL Server)

Aplica-se a:SQL Server

Este artigo descreve como executar um failover forçado (com possível perda de dados) em um grupo de disponibilidade Always On usando o SQL Server Management Studio, o Transact-SQL ou o PowerShell no SQL Server. Um failover forçado é uma forma de failover manual cujo objetivo é estritamente a recuperação de desastres, quando um failover manual planejado não é possível. Se você forçar o failover em uma réplica secundária não sincronizada, talvez ocorra alguma perda de dados. Portanto, recomendamos veementemente que você só force o failover se for necessário restaurar o serviço imediatamente para o grupo de disponibilidade e se estiver disposto a correr o risco de perder dados.

Após um failover forçado, o destino de failover no qual o grupo de disponibilidade falhou se torna a nova réplica primária. Os bancos de dados secundários nas réplicas secundárias remanescentes são suspensos e devem ser retomados manualmente. Quando a réplica primária anterior fica disponível, ela faz a transição para a função secundária, fazendo com que os bancos de dados primários anteriores se tornem bancos de dados secundários e transicionem para o SUSPENDED estado. Antes de retomar um banco de dados secundário específico, você poderá recuperar dados dele que foram perdidos. Entretanto, observe que o truncamento do log de transações é adiado em um determinado banco de dados primário enquanto qualquer um dos bancos de dados secundários estiver suspenso.

A execução de um failover forçado é necessária nas seguintes situações de emergência:

• Depois de forçar o quórum no cluster WSFC (quórum forçado), é necessário forçar o failover em cada grupo de disponibilidade (com possível perda de dados). É necessário forçar o failover porque o estado real dos valores do cluster WSFC pode ter sido perdido. Porém, é possível evitar a perda de dados, caso você possa forçar o failover na instância de servidor que estava hospedando a réplica que era a réplica primária antes de forçar o quorum ou em uma réplica secundária que foi sincronizada antes de forçar o quorum. Para obter mais informações, consulte possíveis maneiras de evitar a perda de dados depois que o quorum for forçado, mais adiante neste artigo.

  Importante

  Se o quorum for recuperado naturalmente em vez de ser forçado, as réplicas de disponibilidade passarão pelo processo de recuperação normal. Se a réplica primária ainda não estiver disponível após o quorum ser recuperado, será possível executar um failover manual planejado em uma réplica secundária sincronizada.

  Para obter mais informações sobre como forçar o quorum, confira Recuperação de desastres do WSFC por meio de quorum forçado (SQL Server). Para obter informações sobre por que é necessário forçar um failover após forçar o quorum, confira Failover e modos de failover (grupos de disponibilidade Always On).

• Se a réplica primária ficar indisponível quando o cluster WSFC tiver um quorum saudável, você poderá forçar o failover (com possível perda de dados) para qualquer réplica cuja função esteja no estado SECONDARY ou RESOLVING. Se possível, force o failover em uma réplica secundária de confirmação síncrona que foi sincronizada quando a réplica primária foi perdida.

  Dica

  Quando o cluster WSFC tiver um quorum íntegro, se você emitir um comando para forçar o failover em uma réplica secundária sincronizada, a réplica executará, na verdade, um failover manual planejado.

Para obter mais informações sobre os pré-requisitos e recomendações para forçar o failover e para um cenário de exemplo que usa um failover forçado para se recuperar de uma falha catastrófica, consulte Exemplo de cenário: Use um failover forçado para se recuperar de uma falha catastrófica, mais adiante neste artigo.

Limitações

• A única vez que você não pode executar um failover forçado é quando o cluster do Windows Server Failover Clustering (WSFC) não tem quorum.

• Pode ocorrer perda de dados durante o failover forçado de um grupo de disponibilidade. Além disso, se a réplica primária estiver em execução quando você iniciar um failover forçado, os clientes ainda poderão ser conectados a bancos de dados primários antigos. Portanto, é altamente recomendável forçar failover apenas se a réplica primária não estiver mais em execução e se você estiver disposto a arriscar a perda de dados para restaurar o acesso aos bancos de dados no grupo de disponibilidade.

• Quando um banco de dados secundário está no estado REVERTING ou INITIALIZING, forçar o failover faria o banco de dados falhar ao iniciar como um banco de dados primário. Se o banco de dados estiver no INITIALIZING estado, você precisará aplicar os registros de log ausentes de um backup de banco de dados ou restaurar totalmente o banco de dados do zero. Se o banco de dados estiver no REVERTING estado, você precisará restaurar totalmente o banco de dados de backups.

• Um comando de failover é retornado assim que o destino de failover aceita o comando. No entanto, a recuperação do banco de dados ocorre de forma assíncrona depois que o grupo de disponibilidade tiver concluído o failover.

• A consistência do banco de dados entre bancos de dados dentro do grupo de disponibilidade pode não ser mantida no failover.

  Observação

  O suporte a transações distribuídas e entre bancos de dados varia conforme as versões do SQL Server e do sistema operacional. Para obter mais informações, consulte Transações – grupos de disponibilidade e espelhamento de banco de dados.

Pré-requisitos

• O cluster WSFC tem quorum. Se o cluster não tiver quorum, confira Recuperação de desastres do WSFC por meio de quorum forçado (SQL Server).

• Você deve ser capaz de se conectar a uma instância de servidor que hospeda uma réplica cuja função está no estado SECONDARY ou no estado RESOLVING.

Recomendações

• Não force o failover enquanto a réplica primária ainda estiver em execução.

• Se possível, force o failover somente em um destino de failover cujos bancos de dados secundários estejam no estado NOT SYNCHRONIZED, SYNCHRONIZED ou SYNCHRONIZING. Para obter informações sobre as implicações de forçar o failover quando um banco de dados secundário estiver no estado INITIALIZING ou no estado REVERTING, consulte Limitações mencionadas anteriormente neste artigo.

• Normalmente, a latência de um determinado banco de dados secundário, relativo ao banco de dados primário, deve ser semelhante em réplicas secundárias de confirmação assíncrona diferentes. Porém, ao forçar failover, a perda de dados pode ser uma preocupação significativa. Portanto, dedique um tempo para determinar a latência relativa das cópias dos bancos de dados em diferentes réplicas secundárias. Para determinar qual cópia de um banco de dados secundário específico apresenta a menor latência, compare os LSNs do final do log. Quanto maior o LSN no final do log, menor a latência.

  Dica

  Para comparar LSNs de fim de log, conecte-se a cada réplica secundária online, uma de cada vez, e consulte sys.dm_hadr_database_replica_states para obter o valor end_of_log_lsn de cada banco de dados secundário local. Em seguida, compare os LSNs de fim de log das diferentes cópias de cada banco de dados. Bancos de dados diferentes podem ter seus LSNs mais altos em réplicas secundárias diferentes. Nesse caso, o destino de failover mais apropriado depende da importância relativa que você coloca nos dados nos bancos de dados diferentes. Ou seja, para qual desses bancos de dados você mais desejaria minimizar a possível perda de dados?

• Se os clientes puderem conectar-se ao original primário, um failover forçado apresentará certo risco de comportamento de partição de rede. Antes de forçar um failover, é altamente recomendável evitar que os clientes acessem a réplica primária original. Caso contrário, depois que o failover for forçado, os bancos de dados primários originais e o bancos de dados primários atuais poderão ser atualizados independentemente uns dos outros.

Possíveis maneiras de evitar a perda de dados depois que o quorum é forçado

Em algumas condições de falha após a perda de quorum, você pode evitar a perda de dados da seguinte maneira:

• Se a réplica primária original ficar disponível

  Se o quorum for perdido e a ação de forçar o quorum WSFC restaurar o nó de cluster que hospeda a réplica primária de um grupo de disponibilidade, você poderá impedir a perda de dados para esse grupo de disponibilidade. Conecte-se à réplica primária e execute um failover forçado (FAILOVER_ALLOW_DATA_LOSS). Isso coloca a réplica primária novamente online. Como o failover forçado é executado na réplica primária original, não há perda de dados.

• Se uma réplica secundária de confirmação síncrona sincronizada ficar online

  Se o quorum for perdido e a ação de forçar o quorum WSFC restaurar um nó de cluster que hospeda uma réplica secundária sincronizada de um grupo de disponibilidade, você poderá impedir a perda de dados para esse grupo de disponibilidade. Se o nó restaurado estava ativo no momento em que o quórum foi perdido, você poderá determinar se a perda de dados pode ocorrer em determinado banco de dados consultando a coluna is_failover_ready da exibição de gerenciamento dinâmico sys.dm_hadr_database_replica_cluster_states. Por exemplo, para uma instância de servidor nomeada sql108w2k8r22, emita a seguinte consulta:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Cuidado

  Se o nó restaurado não estava ativo no momento em que o quorum foi perdido, is_failover_ready talvez não reflita o estado real do cluster no momento em que a réplica primária ficou offline. Portanto, o valor is_failover_ready é adequado apenas para o nó do host no momento da falha. Para obter mais informações, confira "Por que o failover forçado é necessário após um quorum forçado" em Failover e modos de failover (grupos de disponibilidade Always On).

  Se is_failover_ready = 1, o banco de dados será marcado como sincronizado no cluster e estará pronto para um failover. Se is_failover_ready = 1 em cada banco de dados em determinada réplica secundária, você poderá executar um failover forçado (FORCE_FAILOVER_ALLOW_DATA_LOSS), sem perda de dados, nessa réplica secundária. A réplica secundária sincronizada entra online na função primária, ou seja, como a nova réplica primária, com todos os dados intactos.

  Se is_failover_ready = 0, o banco de dados não está marcado como sincronizado no cluster e não está pronto para um failover manual planejado. Se você forçar o failover na réplica secundária do host, os dados serão perdidos nesse banco de dados.

  Observação

  Quando você forçar o failover em uma réplica secundária, a quantidade de perda de dados dependerá de quanto é o atraso do destino de failover subjacente à réplica primária. Infelizmente, quando o cluster WSFC não tem quorum ou o quorum foi imposto, você não pode avaliar a quantidade potencial de perda de dados. Entretanto, observe que, quando o cluster WSFC recuperar um quorum íntegro, será possível começar a controlar a potencial perda de dados. Para obter mais informações, confira "Controle da possível perda de dados" em Failover e modos de failover (grupos de disponibilidade Always On).

Permissões

Requer a permissão ALTER AVAILABILITY GROUP no grupo de disponibilidade, a permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER.

Utilize o SQL Server Management Studio

1. No Pesquisador de Objetos, conecte-se a uma instância de servidor que hospede uma réplica cuja função esteja no estado SECONDARY ou RESOLVING no grupo de disponibilidade que precisa sofrer failover e expanda a árvore de servidores.

2. Expanda os nós Alta Disponibilidade Always On e Grupos de Disponibilidade.

3. Clique com o botão direito do mouse no grupo de disponibilidade que sofrerá failover e selecione o comando Failover.

4. Isso inicia o Assistente de Grupo de Disponibilidade de Failover. Para obter mais informações, confira Usar o Assistente para Executar Failover de Grupo de Disponibilidade (SQL Server Management Studio).

5. Depois de forçar um failover do grupo de disponibilidade, conclua as etapas de acompanhamento necessárias. Para obter mais informações, consulte Acompanhamento: Tarefas essenciais após um failover forçado, mais adiante neste artigo.

Usar Transact-SQL

1. Conecte-se a uma instância de servidor que hospede uma réplica cuja função esteja no estado SECONDARY ou RESOLVING no grupo de disponibilidade que precisa passar por failover.

2. Use a instrução ALTER AVAILABILITY GROUP, como segue, em que group_name é o nome do grupo de disponibilidade:

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   O exemplo a seguir força o grupo de disponibilidade AccountsAG a fazer failover na réplica secundária local.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Depois de forçar um failover do grupo de disponibilidade, conclua as etapas de acompanhamento necessárias. Para obter mais informações, consulte tarefas essenciais após um failover forçado, mais adiante neste artigo.

Usar o PowerShell

1. Altere o diretório (cd) para uma instância de servidor que hospede uma réplica cuja função esteja no estado SECONDARY ou RESOLVING no grupo de disponibilidade que precisa passar por failover.

2. Use o cmdlet Switch-SqlAvailabilityGroup com o parâmetro AllowDataLoss em um dos seguintes formatos:

   • -AllowDataLoss

     Por padrão, o parâmetro -AllowDataLoss faz com que Switch-SqlAvailabilityGroup solicite sua confirmação, lembrando-o de que forçar o failover pode resultar na perda de transações não confirmadas. Para continuar, insira Y; para cancelar a operação, insira N.

     O exemplo a seguir executa um failover forçado (com possível perda de dados) do grupo de disponibilidade MyAg para a réplica secundária na instância de servidor chamada SecondaryServer\InstanceName. Você será solicitado a confirmar essa operação.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Para iniciar um failover forçado sem confirmação, especifique os parâmetros -AllowDataLoss e -Force. Isso será útil se você desejar incluir o comando em um script e executá-lo sem interação do usuário. No entanto, use a opção -Force com cuidado, pois um failover forçado pode resultar na perda de dados de bancos de dados participantes do grupo de disponibilidade.

     O exemplo a seguir executa um failover forçado (com possível perda de dados) do grupo de disponibilidade MyAg na instância de servidor denominada SecondaryServer\InstanceName. A -Force opção suprime a confirmação dessa operação.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Observação

   Para exibir a sintaxe de um cmdlet, use o Get-Help cmdlet no ambiente do SQL Server PowerShell. Para obter mais informações, consulte Get Help SQL Server PowerShell.

3. Depois de forçar um failover do grupo de disponibilidade, conclua as etapas de acompanhamento necessárias. Para obter mais informações, consulte Acompanhamento: Tarefas essenciais após um failover forçado, mais adiante neste artigo.

Configurar e usar o provedor do SQL Server PowerShell

• Provedor do SQL Server PowerShell

Acompanhamento: Tarefas essenciais após um failover forçado

1. Depois de um failover forçado, a réplica secundária na qual foi feito o failover se tornará a nova réplica primária. No entanto, para tornar essa réplica de disponibilidade acessível aos clientes, você pode precisar reconfigurar o quorum WSFC ou ajustar a configuração do modo de disponibilidade do grupo de disponibilidade, da seguinte maneira:

   • Se você fez failover fora do conjunto de failover automático: ajuste os votos de quorum dos nós WSFC para refletir a nova configuração do grupo de disponibilidade. Se o nó WSFC, que hospeda a réplica secundária de destino, não tiver um voto de quorum WSFC, você poderá precisar forçar o quorum WSFC.

     Um conjunto de failover automático existirá apenas se duas réplicas de disponibilidade (inclusive a réplica primária anterior) estiverem configuradas para modo de confirmação síncrona com failover automático.

     Para ajustar votos de quorum

     • Exibir configurações de NodeWeight do quorum do cluster
     • Configurar as definições de NodeWeight do quórum do cluster
     • Forçar um cluster WSFC a iniciar sem quórum

   • Se você fez failover fora do conjunto de failover de confirmação síncrona: será recomendável considerar o ajuste do modo de disponibilidade e do modo de failover na nova réplica primária e nas réplicas secundárias restantes para refletir a confirmação síncrona desejada e a configuração de failover automático.

     Observação

     Um conjunto de failover de confirmação síncrona existe somente se a réplica primária atual estiver configurada para o modo de confirmação síncrona.

     Para alterar o modo de disponibilidade e o modo de failover

     • Alterar o modo de disponibilidade de uma réplica em um grupo de disponibilidade Always On
     • Alterar o modo de failover de uma réplica dentro de um grupo de disponibilidade Always On

2. Depois de 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 ficar online novamente e descobrir que agora ela é uma réplica secundária. É necessário retomar manualmente cada banco de dados suspenso individualmente em cada réplica secundária.

   Quando um banco de dados secundário é retomado, ele inicia a sincronização de dados com o banco de dados primário correspondente. O banco de dados secundário reverte os registros de log que nunca foram confirmados no novo banco de dados primário. Portanto, se você estiver preocupado com a possível perda de dados nos bancos de dados primários após o failover, tente criar um instantâneo do banco de dados nos bancos de dados suspensos em um dos bancos de dados secundários de confirmação síncrona.

   Importante

   O truncamento do log de transações será atrasado em um banco de dados primário enquanto um de seus bancos de dados secundários estiver suspenso. Além disso, a integridade da sincronização de uma réplica secundária de confirmação síncrona não poderá fazer a transição para HEALTHY enquanto um banco de dados local permanecer suspenso.

   Para criar um instantâneo do banco de dados

   • Criar um instantâneo de banco de dados (Transact-SQL)

   Para retomar um banco de dados de disponibilidade

   • Retomar um banco de dados de disponibilidade (SQL Server)

   Cuidado

   Antes de tentar um failover do grupo novamente, depois de retomar todos os bancos de dados secundários, espere que todos os bancos de dados secundários no próximo destino de failover entrem no estado SYNCHRONIZING. Se qualquer banco de dados ainda não estiver no estado SYNCHRONIZING, esse banco de dados será impedido de entrar online como um banco de dados primário, e o restabelecimento da sincronização de dados para o banco de dados poderá exigir a restauração dos logs de transações, a restauração do backup completo do banco de dados ou o failover para a réplica primária anterior.

3. Se uma réplica de disponibilidade com falha não estiver retornando à réplica de disponibilidade ou retornar muito tarde para você atrasar o truncamento do log de transações no novo banco de dados primário, considere remover a réplica com falha do grupo de disponibilidade para evitar a falta de espaço em disco para seus arquivos de log.

   Para remover uma réplica secundária

   • Remover uma réplica secundária de um grupo de disponibilidade (SQL Server)

4. Se você seguir um failover forçado com um ou mais failovers forçados adicionais, execute um backup de log depois de cada failover forçado adicional na série. Para obter informações sobre a razão para isso, confira "Riscos de forçar o failover" na seção "Failover manual forçado (com possível perda de dados)" de Failover e modos de failover (grupos de disponibilidade Always On).

   Para realizar um backup de log

   • Fazer backup de um log de transações

Cenário de exemplo: usar um failover forçado para recuperar-se de uma falha catastrófica

Se a réplica primária falhar e nenhuma réplica secundária sincronizada estiver disponível, forçar o grupo de disponibilidade a realizar failover poderá ser uma resposta apropriada. A conveniência de forçar um failover depende de: (1) se você espera que a réplica primária fique offline por mais tempo que seu SLA (contrato de nível de serviço) tolera e (2) se você está disposto a correr o risco de uma potencial perda de dados para disponibilizar os bancos de dados primários rapidamente. Se você decidir que um grupo de disponibilidade exige um failover forçado, o failover forçado real será apenas uma etapa de um processo de várias etapas.

Para ilustrar as etapas necessárias para usar um failover forçado para se recuperar de uma falha catastrófica, este artigo apresenta um possível cenário de recuperação de desastre. O cenário de exemplo considera um grupo de disponibilidade cuja topologia original consiste em um data center principal que hospeda três réplicas de disponibilidade de confirmação síncrona, incluindo a réplica primária, e um data center remoto que hospeda duas réplicas secundárias de confirmação assíncrona. A figura a seguir ilustra a topologia original deste exemplo de grupo de disponibilidade. O grupo de disponibilidade está hospedado por um cluster WSFC de várias sub-redes com três nós no data center principal (Nó 01, Nó 02e Nó 03) e dois nós em um data center remoto (Nó 04 e Nó 05).

O data center principal é desligado inesperadamente. Suas três réplicas de disponibilidade ficam offline, e seus bancos de dados ficam indisponíveis. A figura a seguir ilustra o efeito dessa falha na topologia do grupo de disponibilidade.

O DBA (administrador de banco de dados) determina que a melhor resposta possível é forçar o failover do grupo de disponibilidade para uma das réplicas secundárias de confirmação assíncrona remotas. Este exemplo ilustra as etapas típicas envolvidas quando você força o failover do grupo de disponibilidade para uma réplica remota e, consequentemente, retorna o grupo de disponibilidade a sua topologia original.

A resposta da falha apresentada aqui consiste nas duas fases a seguir:

• Responder à falha catastrófica do data center principal
• Retornar o grupo de disponibilidade à sua topologia original

Responder à falha catastrófica do data center principal

A figura a seguir ilustra a série de ações realizadas no data center remoto em resposta à falha catastrófica no data center principal.

As etapas nesta figura indicam as etapas a seguir:

Retornar o grupo de disponibilidade à sua topologia original

A figura a seguir ilustra a série de ações que retornam o grupo de disponibilidade a sua topologia original depois que o data center principal volta a ficar online e os nós WSFC restabelecem comunicação com o cluster WSFC.

As etapas nesta figura indicam as etapas a seguir:

Tarefas relacionadas

Ajustar votos de quórum

• Exibir configurações de NodeWeight do quorum do cluster
• Configurar as definições de NodeWeight do quórum do cluster
• Forçar um cluster WSFC a iniciar sem quórum

Failover manual planejado

• Executar um failover manual planejado de um grupo de disponibilidade Always On (SQL Server)
• Usar o Assistente para Grupo de Disponibilidade de Failover (SQL Server Management Studio)

Troubleshoot

• Solucionar problemas na configuração de Grupos de Disponibilidade Always On (SQL Server)
• Solução de problemas de operação adicionar arquivos com falha (grupos de disponibilidade de AlwaysOn)

Conteúdo relacionado

• Blogs da equipe do AlwaysOn do SQL Server: o blog oficial da equipe do AlwaysOn do SQL Server
• Blogs dos engenheiros do CSS SQL Server
• Guia de soluções AlwaysOn do Microsoft SQL Server para alta disponibilidade e recuperação de desastre
• O que é um grupo de disponibilidade Always On?
• Diferenças entre os modos de disponibilidade de um grupo de disponibilidade Always On
• Failover e modos de failover (Grupos de Disponibilidade AlwaysOn)
• Tipos de conexões de cliente com as réplicas em um grupo de disponibilidade Always On
• Ferramentas para monitorar grupos de disponibilidade AlwaysOn
• Clustering de Failover do Windows Server com o SQL Server