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, Transact-SQL ou PowerShell no SQL Server. Um failover forçado é uma forma de failover manual que se destina estritamente à recuperação de desastres, quando um failover manual planeado não é possível. Se forçar o failover para uma réplica secundária não sincronizada, pode ocorrer alguma perda de dados. Portanto, é altamente recomendável que você force o failover somente se precisar restaurar o serviço para o grupo de disponibilidade imediatamente e estiver disposto a correr o risco de perder dados.

Após um failover forçado, o alvo de failover para o qual o grupo de disponibilidade foi transferido torna-se a nova réplica primária. Os bancos de dados secundários nas réplicas secundárias restantes são suspensos e devem ser retomados manualmente. Quando a réplica primária anterior fica disponível, ela transita para a função secundária, fazendo com que os bancos de dados primários anteriores se tornem bancos de dados secundários e façam a transição para o SUSPENDED estado. Antes de retomar um determinado banco de dados secundário, você poderá recuperar dados perdidos dele. No entanto, tenha em atenção que o truncamento do log de transações está atrasado num banco de dados primário enquanto um dos seus bancos de dados secundários está 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), deves forçar o failover de cada um dos grupos de disponibilidade, com possível perda de dados. Forçar o failover é necessário porque o estado real dos valores do cluster WSFC pode ter sido perdido. No entanto, você pode evitar a perda de dados se conseguir 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 quórum ou para uma réplica secundária que foi sincronizada antes de forçar o quórum. Para obter mais informações, consulte Maneiras potenciais de evitar a perda de dados após o quórum ser forçado, mais adiante neste artigo.

  Importante

  Se o quórum for restabelecido por meios naturais em vez de ser forçado, as réplicas de disponibilidade realizam uma recuperação normal. Se a réplica primária ainda estiver indisponível após a recuperação do quórum, você poderá executar um failover manual planejado para uma réplica secundária sincronizada.

  Para obter informações sobre como forçar quórum, consulte WSFC Disaster Recovery through Forced Quorum (SQL Server). Para obter informações sobre por que é necessário forçar o failover depois de forçar o quórum, consulte 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 quórum saudável, é possível forçar o failover (com possível perda de dados) para qualquer réplica cuja função esteja no estado de SECONDARY ou RESOLVING. Se possível, force o failover para 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 quórum íntegro, se você emitir um comando force failover em uma réplica secundária sincronizada, a réplica realmente executará um failover manual planejado.

Para obter mais informações sobre os pré-requisitos e recomendações para forçar mudança de sistema e para um cenário de exemplo que usa uma mudança de sistema forçada para recuperar-se de uma falha catastrófica, veja Cenário de exemplo: usar uma mudança de sistema forçada para recuperar-se de uma falha catastrófica, mais adiante neste artigo.

Limitações

• O único momento em que você não pode executar um failover forçado é quando o cluster WSFC (Cluster de Failover do Windows Server) não tem quórum.

• Pode haver 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 estar conectados a bancos de dados primários anteriores. Portanto, é altamente recomendável que você force o failover somente se a réplica primária não estiver mais em execução e se 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 a alternância de função causaria uma falha na inicialização do banco de dados como primário. Se o banco de dados estava no INITIALIZING estado, então você precisa aplicar os registros de log ausentes de um backup de banco de dados ou restaurar totalmente o banco de dados a partir do zero. Se o banco de dados estiver no estado REVERTING, você precisa restaurar totalmente o banco de dados a partir de backups.

• Um comando failover retorna assim que o destino de failover aceita o comando. No entanto, a recuperação do banco de dados ocorre de forma assíncrona após o failover do grupo de disponibilidade.

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

  Observação

  O suporte para transações distribuídas e entre bancos de dados varia de acordo com o SQL Server e as 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 quórum. Se o cluster não tiver quórum, consulte WSFC Disaster Recovery through Forced Quorum (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 RESOLVING.

Recomendações

• Não force o failover enquanto a réplica principal 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 failover quando um banco de dados secundário está no estado INITIALIZING ou REVERTING, consulte Limitações anteriormente neste artigo.

• Normalmente, a latência de um determinado banco de dados secundário, em relação ao banco de dados primário, deve ser semelhante em diferentes réplicas secundárias de confirmação assíncrona. No entanto, ao forçar o failover, a perda de dados pode ser uma preocupação significativa. Portanto, considere levar 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 possui a menor latência, compare seus LSNs de fim de log. Quanto maior o LSN de fim de log, menor a latência.

  Dica

  Para comparar os LSNs de fim de log, conecte-se a cada réplica secundária online, por sua vez, e consulte sys.dm_hadr_database_replica_states para obter o end_of_log_lsn 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, os alvos de recuperação mais apropriados dependem da importância relativa que se atribui aos dados nos diferentes bancos de dados. Ou seja, para qual desses bancos de dados você mais gostaria de minimizar a possível perda de dados?

• Se os clientes são capazes de se conectar ao primário original, um failover forçado incorre em algum risco de comportamento cerebral dividido. Antes de forçar o failover, é altamente recomendável impedir que os clientes acessem a réplica primária original. Caso contrário, após o failover ser forçado, os bancos de dados primários originais e os bancos de dados primários atuais poderão ser atualizados independentemente um do outro.

Maneiras potenciais de evitar a perda de dados após forçar o quórum

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

• Se a réplica primária original ficar online

  Se o quórum for perdido e forçar o quórum do WSFC restaurará o nó do cluster que hospeda a réplica primária de um grupo de disponibilidade, você poderá evitar 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 principal online novamente. 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 sincronizada de confirmação síncrona ficar online

  Se o quórum for perdido e forçar o quórum do WSFC restaurará um nó de cluster que hospeda uma réplica secundária sincronizada para um grupo de disponibilidade, você deverá ser capaz de evitar a perda de dados para esse grupo de disponibilidade. Se o nó restaurado estava ativo no momento em que o quórum foi perdido, pode-se determinar se pode haver perda de dados em um determinado banco de dados consultando a coluna is_failover_ready da vista de gestão dinâmica sys.dm_hadr_database_replica_cluster_states. Por exemplo, para uma instância de servidor chamada 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'
  );
  

  Atenção

  Se o nó restaurado não estava ativo no momento em que o quórum foi perdido, is_failover_ready pode não refletir o estado real do cluster no momento em que a réplica primária ficou offline. Portanto, o valor is_failover_ready só é bom se o nó do host estiver no momento da falha. Para obter mais informações, consulte "Por que o failover forçado é necessário após forçar o quórum" em failover e modos de failover (Grupos de Disponibilidade Always On).

  Se is_failover_ready = 1, o banco de dados está marcado como sincronizado no cluster e está pronto para um failover. Caso is_failover_ready = 1 esteja presente em cada base de dados de uma determinada réplica secundária, é possível 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 fica online na função principal, 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 planeado. Se você forçar o failover para a réplica secundária do host, os dados serão perdidos nesse banco de dados.

  Observação

  Quando se força o failover para uma réplica secundária, a quantidade de perda de dados depende de quão longe a réplica de destino para o failover está atrasada em relação à réplica primária. Infelizmente, quando o cluster WSFC não possui quórum ou o quórum foi forçado, não é possível avaliar a quantidade de perda potencial de dados. Observe, no entanto, que assim que o cluster WSFC recuperar um quórum íntegro, você poderá começar a rastrear possíveis perdas de dados. Para obter mais informações, consulte "Rastreio de Perda Potencial de Dados" em Failover e Modos de Failover (Grupos de Disponibilidade Always On).

Permissões

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

Utilize 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 SECONDARY estado ou RESOLVING no grupo de disponibilidade que precisa ser submetido a failover e expanda a árvore do servidor.

2. Expanda o nó de Alta Disponibilidade Always On e o nó Availability Groups.

3. Clique com o botão direito do rato no grupo de disponibilidade para realizar um failover e selecione o comando Failover.

4. Isso inicia o Assistente de Grupo de Disponibilidade de Failover. Para obter mais informações, consulte Utilizar o Assistente de Grupo de Disponibilidade de Recuperação (SQL Server Management Studio).

5. Depois de forçar um grupo de disponibilidade a fazer failover, 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.

Utilize o Transact-SQL

1. Conecte-se a uma instância de servidor que hospeda uma réplica cuja função está no SECONDARY estado ou RESOLVING no grupo de disponibilidade que precisa ser submetido a failover.

2. Use a instrução ALTER AVAILABILITY GROUP , da seguinte forma, 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 para a réplica secundária local.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Depois de forçar um grupo de disponibilidade a fazer failover, 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.

Utilizar 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 transferido.

2. Use o Switch-SqlAvailabilityGroup cmdlet com o AllowDataLoss parâmetro numa das seguintes formas:

   • -AllowDataLoss

     Por padrão -AllowDataLoss , o parâmetro permite que Switch-SqlAvailabilityGroup lhe lembre que forçar o failover pode resultar na perda de transações não confirmadas e solicite confirmação. Para continuar, digite Y; para cancelar a operação, digite 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 do servidor chamada SecondaryServer\InstanceName. Você será solicitado a confirmar esta 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 é útil se você quiser incluir o comando em um script e executá-lo sem interação do usuário. No entanto, utilize a opção -Force com cuidado, pois um failover forçado pode resultar na perda de dados nos bancos de dados que participam do grupo de disponibilidade.

     O exemplo a seguir executa um failover forçado (com possível perda de dados) do grupo de disponibilidade MyAg para a instância do servidor chamada SecondaryServer\InstanceName. A -Force opção suprime a confirmação desta 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 Obter Ajuda do SQL Server PowerShell.

3. Depois de forçar um grupo de disponibilidade a fazer failover, 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. Após um failover forçado, a réplica secundária para a qual você fez failover se torna a nova réplica primária. No entanto, para tornar essa réplica de disponibilidade acessível aos clientes, talvez seja necessário reconfigurar o quorum do 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 quórum dos nós WSFC para refletir sua nova configuração de grupo de disponibilidade. Se o nó do WSFC que hospeda a réplica secundária de destino não tiver uma votação de quórum do WSFC, talvez seja necessário forçar o quórum do WSFC.

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

     Ajustar as votações do quórum

     • Exibir configurações de peso do nó do quórum do cluster
     • Definir configurações de NodeWeight do Quórum de Cluster
     • Forçar um Cluster WSFC a Iniciar Sem Quórum

   • Se ocorreu um failover fora do conjunto de failover de confirmação síncrona: É 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 que reflictam a sua configuração desejada de confirmação síncrona e failover automático.

     Observação

     Um conjunto de recuperação por confirmação síncrona só existe se a réplica primária atual estiver configurada no 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 dentro de um grupo de disponibilidade Always On
     • Alterar o modo de failover de uma réplica num grupo de disponibilidade Always On

2. 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 réplica primária anterior volta a estar 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 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 anula todos os registros de log que nunca foram efetivados no novo banco de dados primário. Portanto, caso esteja preocupado com a possível perda de dados nos bancos de dados primários após o failover, deve tentar criar um instantâneo dos 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 é atrasado numa base de dados primária enquanto qualquer das suas bases de dados secundárias está suspensa. Além disso, a integridade da 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 de banco de dados

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

   Para retomar um banco de dados de disponibilidade

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

   Atenção

   Depois de recuperar todos os bancos de dados secundários, antes de tentar proceder ao failover do 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 o restabelecimento da sincronização de dados para o banco de dados pode exigir a restauração de logs de transações, a restauração de um backup completo do banco de dados ou o failover de volta para a réplica primária anterior.

3. Se uma réplica de disponibilidade que falhou não estiver retornando à réplica de disponibilidade ou puder retornar tarde demais para 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 ficar 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 após cada failover forçado adicional na série. Para obter informações sobre o motivo para isso, consulte "Riscos de Forçar 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 executar um backup de log

   • Fazer backup de um log de transações

Cenário de exemplo: utilize um failover forçado para 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 fazer failover pode ser uma resposta apropriada. A adequação de forçar um failover depende: (1) se você espera que a réplica principal fique offline por mais tempo do que o seu contrato de nível de serviço (SLA) tolera e (2) se você está disposto a arriscar uma possível perda de dados para disponibilizar bancos de dados primários rapidamente. Se você decidir que um grupo de disponibilidade requer um failover forçado, o failover forçado real é 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 desastres. 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 seguinte ilustra a topologia original deste grupo de disponibilidade de exemplo. O grupo de disponibilidade é 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 centro de dados principal desliga-se 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 administrador de banco de dados (DBA) determina que a melhor resposta possível é forçar o failover do grupo de disponibilidade para uma das réplicas secundárias remotas de confirmação assíncrona. Este exemplo ilustra as etapas típicas envolvidas quando você força o failover do grupo de disponibilidade para uma réplica remota e, eventualmente, retorna o grupo de disponibilidade à sua topologia original.

A resposta à falha aqui apresentada consiste nas duas fases seguintes:

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

Responder à falha catastrófica do data center principal

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

As etapas nesta figura indicam as seguintes etapas:

Retornar o grupo de disponibilidade à topologia original

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

As etapas nesta figura indicam as seguintes etapas:

Tarefas relacionadas

Ajustar os votos do quórum

• Exibir configurações de peso do nó do quórum do cluster
• Definir configurações de NodeWeight do Quórum de Cluster
• Forçar um Cluster WSFC a Iniciar Sem Quórum

Falha manual planeada

• 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 de configuração de grupos de disponibilidade Always On (SQL Server)
• solucionar uma falha na operação de Add-File (Grupos de Disponibilidade Always On)

Conteúdo relacionado

• Blogue Oficial da Equipa Always On do SQL Server
• Blogs de engenheiros do SQL Server CSS
• Guia de soluções Always On do Microsoft SQL Server para alta disponibilidade e recuperação de desastres
• O que é um grupo de disponibilidade Always On?
• Diferenças entre os modos de disponibilidade para um grupo de disponibilidade Always On
• Modos de Failover e Failover (Grupos de Disponibilidade Always On)
• Tipos de conexões de cliente com réplicas dentro de um grupo de disponibilidade Always On
• Ferramentas para monitorar grupos de disponibilidade Always On
• Cluster de Failover do Windows Server com o SQL Server