Executar um failover manual e 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 destinada exclusivamente à 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 que você só force o failover se precisar restaurar o serviço para o grupo de disponibilidade imediatamente e ainda assim 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 será atrasado em um determinado banco de dados primário enquanto qualquer um de seus bancos de dados secundários esteja 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. No entanto, você poderá evitar a perda de dados se for capaz de forçar o failover na instância do servidor que estava hospedando a réplica que era a réplica primária antes de forçar o quorum ou para uma réplica secundária que foi sincronizada antes do quorum forçado. 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 por meios naturais em vez de ser forçado, as réplicas de disponibilidade passarão pela 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.

• A perda de dados é possível 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, recomendamos que você force o failover somente se a réplica primária não estiver mais em execução e se você estiver disposto a correr o risco de perder 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 de banco de dados ocorre de forma assíncrona depois que o grupo de disponibilidade terminar 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 bancos de dados varia de acordo com o SQL Server e versões 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 apenas para 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 determinado banco de dados secundário tem a menor latência, compare os LSNs de fim de log delas. Um LSN de fim de log mais alto indica menos latência.

  Dica

  Para comparar LSNs de fim de log, conecte-se a cada réplica secundária online, uma a uma, e consulte sys.dm_hadr_database_replica_states para obter o valor 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. Neste 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 divisão de dados. 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 online

  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 você executa o failover forçado para a 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ê deverá ser capaz de impedir a perda de dados para esse grupo de disponibilidade. Se o nó restaurado estava ativo no momento em que o quorum foi perdido, você pode determinar se ocorrerá perda de dados em um 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 só será válido se o nó do host estiver em determinado estado 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, então o banco de dados está marcado como sincronizado no cluster e está pronto para um failover. Se is_failover_ready = 1 em cada banco de dados em uma determinada réplica secundária, você poderá executar um failover forçado (FORCE_FAILOVER_ALLOW_DATA_LOSS) sem perda de dados nesta 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 estiver marcado como sincronizado no cluster e não estiver pronto para um failover manual planejado. Se você forçar o failover para a réplica secundária do host, haverá perda de dados neste banco de dados.

  Observação

  Quando você força o failover para uma réplica secundária, a quantidade de perda de dados depende de quão longe o destino de failover está ficando para trás da 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 “Controlando a potencial perda de dados” em Failover e modos de failover (grupos de disponibilidade Always On).

Permissões

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

Utilize o SQL Server Management Studio

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

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

3. Clique com o botão direito do mouse no grupo de disponibilidade do qual fazer 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 hospeda uma réplica cuja função está nos estados SECONDARY ou RESOLVING no grupo de disponibilidade que precisa ser reconfigurado em um processo de failover.

2. Use a instrução ALTER AVAILABILITY GROUP da seguinte maneira, onde 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 ser sujeito a failover.

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

   • -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 na réplica secundária na instância de servidor denominada 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 torna 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 quórum do WSFC, pode ser necessário forçar o quórum do 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 de quorum do cluster
     • Definir configurações de NodeWeight de quorum do cluster
     • Forçar um cluster WSFC para iniciar sem um quorum

   • 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 existirá somente se a réplica primária atual for configurada para 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 em 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 bancos de dados primários anteriores, depois que a réplica primária anterior 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.

   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 de banco de dados nos bancos de dados suspensos em um dos bancos de dados secundários com confirmação síncrona.

   Importante

   O truncamento do log de transações será atrasado em um banco de dados primário enquanto qualquer um de seus bancos de dados secundários estiver suspenso. Além disso, a integridade de sincronização de uma réplica secundária de confirmação síncrona não pode fazer a transição para HEALTHY enquanto qualquer 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

   Depois de retomar todos os bancos de dados secundários, antes de tentar realizar failover no grupo novamente, aguarde até que cada banco de dados secundário no próximo destino de failover entre no estado SYNCHRONIZING. Se algum banco de dados ainda SYNCHRONIZINGnão estiver , esse banco de dados será impedido de ficar online como um banco de dados primário e restabelecer a sincronização de dados para o banco de dados poderá exigir a restauração de logs de transações, a restauração de um backup de banco de dados completo ou o failover para a réplica primária anterior.

3. Se uma réplica de disponibilidade que falhou não estiver retornando ao grupo de disponibilidade ou puder retornar tarde demais para você adiar o truncamento do log de transações na nova réplica primária, considere remover a réplica com falha do grupo de disponibilidade para evitar que você fique sem 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 se recuperar 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 adequação de forçar um failover depende de: (1) se você espera que a réplica primária fique offline por mais tempo do que o SLA (contrato de nível de serviço) tolera e (2) se você está disposto a arriscar a perda de dados potencial para disponibilizar 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 grupo de disponibilidade de exemplo. 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 os 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 de quorum do cluster
• Definir configurações de NodeWeight de quorum do cluster
• Forçar um cluster WSFC para iniciar sem um quorum

Failover manual planejado

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

Troubleshoot

• Solucionar problemas de configuração de grupos de disponibilidade AlwaysOn (SQL Server)
• Solução de problemas de uma operação de 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 réplicas em um grupo de disponibilidade Always On
• Ferramentas para monitorar grupos de disponibilidade AlwaysOn
• Clustering de Failover do Windows Server com SQL Server