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

Este tópico descreve como executar um failover forçado (com possível perda de dados) em um grupo de disponibilidade AlwaysOn usando o SQL Server Management Studio, o Transact-SQL ou o PowerShell no SQL Server 2012. Um failover forçado é uma forma de failover manual cujo objetivo é estritamente a recuperação de desastres, quando 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 expressamente forçar o failover apenas se for necessário restaurar serviço imediatamente para o grupo de disponibilidade e se você quiser 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 antiga réplica primária ficar disponível, ela fará a transição para a função secundária, fazendo com que os antigos bancos de dados primários se tornem bancos de dados secundários e passem para o estado SUSPENDED. 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ção é atrasado em um banco de dados primário específico enquanto qualquer um de seus bancos de dados secundários é suspenso.

Importante
A sincronização de dados com o banco de dados primário só ocorrerá depois que o banco de dados secundário for retomado. Para obter mais informações sobre como retomar um banco de dados secundário, consulte Tarefas essenciais depois de um failover forçado posteriormente neste artigo.

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

• Depois de forçar o quorum no cluster WSFC (quorum 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: se você puder 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 perda de dados após quorum forçado posteriormente neste tópico.

  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 quorum forçado, consulte Recuperação de desastres WSFC por meio de quorum forçado (SQL Server). Para obter informações sobre por que é necessário forçar o failover depois de forçar o quorum, consulte Failover e modos de failover (grupos de disponibilidade AlwaysOn).

• Se a réplica primária ficar indisponível enquanto o cluster WSFC tiver um quorum íntegro, você poderá forçar o failover (com possível perda de dados) em 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.

Observação
Para obter mais informações sobre os pré-requisitos e as recomendações para forçar o failover e para um cenário de exemplo que usa um failover forçado para recuperação de uma falha catastrófica, consulte Cenário de exemplo: usando um failover forçado para recuperação de uma falha catastrófica posteriormente neste tópico.

• Antes de começar:  

  Limitações e restrições

  Pré-requisitos

  Recomendações

  Possíveis maneiras de evitar perda de dados após quorum forçado

  Segurança

• Para forçar failover (com possível perda de dados) usando:  

  SQL Server Management Studio

  Transact-SQL

  PowerShell

• Acompanhamento:  Tarefas essenciais depois de um failover forçado

• Exemplo de cenário:  Usando um failover forçado para recuperar de uma falha catastrófica

• Tarefas relacionadas

• Conteúdo relacionado

Antes de começar

Limitações e restrições

• A única vez que você não pode executar um failover forçado é quando o cluster WSFC (Windows Server Failover Clustering) 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, é 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 estiver no estado REVERTING ou INITIALIZING, forçar o failover causaria falha na inicialização do banco de dados como um banco de dados primário. Se o banco de dados estiver no estado INTIAILIZGING, você precisará aplicar os registros de log ausentes de um backup de banco de dados ou restaurar completamente o banco de dados a partir do zero. Se o banco de dados estiver no estado REVERTING, você precisará restaurar completamente o banco de dados dos 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 não é mantida no failover.

  Observação
  Não há suporte para transações entre bancos de dados e transações distribuídas no Grupos de Disponibilidade AlwaysOn. Para obter mais informações, consulte Transações envolvendo todos os bancos de dados sem suporte para espelhamento de banco de dados ou Grupos de Disponibilidade AlwaysOn (SQL Server).

Pré-requisitos

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

• É necessário poder se conectar a uma instância de servidor que hospede uma réplica cuja função esteja no estado SECONDARY ou RESOLVING.

Recomendações

• Não force 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 está no estado INTIAILIZGING ou REVERTING, consulte Limitações e restrições anteriormente neste tópico.

• 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 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. Observe que bancos de dados diferentes podem ter o LSNs mais alto 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 destes 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 perda de dados após quorum forçado

Em algumas condições de falha depois que o quorum é perdido, é possível evitar a perda de dados, como a seguir:

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

  Se o quorum é perdido e forçar o quorum do WSFC restaura o nó de cluster que hospeda a réplica primária de um grupo de disponibilidade, é possível 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 é perdido e forçar o quorum do WSFC restaura um nó de cluster que hospeda uma réplica secundária sincronizada de um grupo de disponibilidade, você deve 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 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 só é adequado para o nó do host no momento da falha. Para obter mais informações, consulte "Por que o failover forçado é necessário após um quorum forçado" em Failover e modos de failover (grupos de disponibilidade AlwaysOn).

  Se is_failover_ready = 1, o banco de dados é marcado como sincronizado no cluster e está pronto para um failover. Se is_failover_ready = 1 em cada banco de dados em determinada réplica secundária, você pode 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 é 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 forçado, não é possível avaliar a quantidade da potencial 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, consulte “Controlando a potencial perda de dados” em Failover e modos de failover (grupos de disponibilidade AlwaysOn).

Segurança

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.

[Início]

Usando o SQL Server Management Studio

Para forçar failover (com possível perda de dados)

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 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, consulte Usar o Assistente para Grupo de Disponibilidade de Failover (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 depois de um failover forçado, posteriormente neste tópico.

[Início]

Usando Transact-SQL

Para forçar failover (com possível perda de dados)

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 sofrer failover.

2. Use a instrução ALTER AVAILABILITY GROUP, da seguinte maneira:

   ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   onde group_name é o nome do grupo de disponibilidade.

   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 Acompanhamento: tarefas essenciais depois de um failover forçado, posteriormente neste tópico.

[Início]

Usando o PowerShell

Para forçar failover (com possível perda de dados)

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 sofrer 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 o Switch-SqlAvailabilityGroup avise você de que o failover forçado pode resultar na perda de transações não confirmadas e a solicitar uma confirmação. Para continuar, digite S. 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 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 de usuário. No entanto, use a opção -Force com cuidado, pois um failover forçado pode resultar na perda de dados dos 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 na instância de servidor denominada SecondaryServer\InstanceName. A opção -Force 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 cmdlet Get-Help no ambiente do SQL Server PowerShell. Para obter mais informações, consulte Obter Ajuda do 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 depois de um failover forçado, posteriormente neste tópico.

Para configurar e usar o provedor do SQL Server PowerShell

• Provedor do SQL Server PowerShell

[Início]

Acompanhamento: tarefas essenciais depois de 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 do WSFC ou ajustar a configuração do modo de disponibilidade do grupo de disponibilidade, da seguinte maneira:

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

     Observação
     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 de cluster

     • Definir configurações de NodeWeight de quorum de 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 de disponibilidade (SQL Server)

     • Alterar o modo de failover de uma réplica de disponibilidade (SQL Server)

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ário de confirmação síncrona.

   Importante
   O truncamento do log de transação é atrasado em um banco de dados primário enquanto qualquer um de seus bancos de dados secundários é 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 qualquer banco de dados local permanecer suspenso.

   Para criar um instantâneo do 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)

   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 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 será retornada à 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 isto, 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 AlwaysOn).

   Para realizar um backup de log

   • Fazer backup de um log de transações (SQL Server)

[Início]

Cenário de exemplo: usando 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 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 (acordo de nível de serviço) tolera e (2) se você está disposto a arriscar perda de dados potencial para tornar bancos de dados primários disponíveis 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 que são necessárias para usar um failover forçado para se recuperar de uma falha catastrófica, este tópico 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 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ó 02 e 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 impacto 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:

• Respondendo à falha catastrófica do data center principal

• Voltando o grupo de disponibilidade a sua topologia original

Respondendo à 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:

Etapa	Ação	Links
1.	O DBA ou administrador da rede verifica se o cluster WSFC tem um quorum íntegro. Neste exemplo, o quorum precisa ser forçado.	Configuração de modos de quorum WSFC e votação (SQL Server) Recuperação de desastres WSFC por meio de quorum forçado (SQL Server)
2.	O DBA conecta-se à instância de servidor com a menor latência (no Nó 04) e executa um failover manual forçado. O failover forçado faz a transição desta réplica secundária para a função primária e suspende os bancos de dados secundários na réplica secundária restante (no Nó 05).	sys.dm_hadr_database_replica_states (Transact-SQL) (Consulte a coluna end_of_log_lsn. Para obter mais informações, consulte Recomendações anteriormente neste tópico.) Executar um failover manual forçado de um grupo de disponibilidade (SQL Server)
3.	O DBA retoma manualmente cada banco de dados secundário na réplica secundária restante.	Retomar um banco de dados de disponibilidade (SQL Server)

[Início]

Voltando o grupo de disponibilidade a 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.

Importante

Se o quorum do cluster WSFC tiver sido forçado, quando os nós offline reiniciam, eles poderão formar um novo quorum se as duas condições a seguir existirem: (um) não há nenhuma conectividade de rede entre qualquer nó no conjunto de quorum forçado e (b) os nós de reinicialização são a maioria dos nós de cluster. Isso resulta em uma condição de divisão de dados, na qual o grupo de disponibilidade teria duas réplicas primárias independentes, uma em cada data center. Antes de forçar quorum para criar um conjunto de quorum minoritário, consulte Recuperação de desastres WSFC por meio de quorum forçado (SQL Server).

As etapas nesta figura indicam as etapas a seguir:

	Etapa	Links
1.	Os nós no data center principal ficam online novamente e restabelecem comunicação com o cluster WSFC. As réplicas de disponibilidade ficam online como réplicas secundárias com bancos de dados suspensos e o DBA precisará retomar manualmente cada desses bancos de dados em breve.	Retomar um banco de dados de disponibilidade (SQL Server) Dica 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ário de confirmação síncrona. Tenha em mente que o truncamento do log de transação é atrasado em um banco de dados primário enquanto qualquer um de seus bancos de dados secundários é suspenso. Além disso, a integridade da sincronização da réplica secundária de confirmação síncrona não poderá fazer a transição para HEALTHY enquanto qualquer banco de dados local permanecer suspenso.
2.	Quando os bancos de dados forem retomados, o DBA alterará a nova réplica primária temporariamente para o modo de confirmação síncrona. Isso envolve duas etapas: Alterar uma réplica de disponibilidade offline para o modo de confirmação assíncrona. Alterar a nova réplica primária para o modo de confirmação síncrona. Observação Esta etapa permite que bancos de dados secundários de confirmação síncrona retomados tornem-se SYNCHRONIZED.	Alterar o modo de disponibilidade de uma réplica de disponibilidade (SQL Server)
3.	Quando a réplica secundária de confirmação síncrona no Nó 03 (a réplica primária original) insere o estado de sincronização HEALTHY, o DBA executa um failover manual planejado para essa réplica, para que ele se torne novamente a réplica primária. A réplica no Nó 04 volta a ser uma réplica secundária.	sys.dm_hadr_database_replica_states (Transact-SQL) Use as políticas AlwaysOn para exibir a integridade de um grupo de disponibilidade (SQL Server) Executar um failover manual planejado de um grupo de disponibilidade (SQL Server)
4.	O DBA conecta-se à nova réplica primária e: Altera a réplica primária antiga (no centro remoto) de volta para o modo de confirmação assíncrona. Altera a réplica secundária de confirmação assíncrona no data center principal de volta para o modo de confirmação síncrona.	Alterar o modo de disponibilidade de uma réplica de disponibilidade (SQL Server)

[Início]

Tarefas relacionadas

Para ajustar votos de quorum

• Exibir configurações de NodeWeight de quorum de cluster

• Definir configurações de NodeWeight de quorum de cluster

• Forçar um cluster WSFC para iniciar sem um quorum

Failover manual planejado:

• Executar um failover manual planejado de um grupo de disponibilidade (SQL Server)

• Usar o Assistente para Grupo de Disponibilidade de Failover (SQL Server Management Studio)

Para solucionar problemas:

• 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)

[Início]

Conteúdo relacionado

• **Blogs: **

  Blogs da equipe do SQL Server AlwaysOn: o blog oficial da equipe do SQL Server AlwaysOn

  Blogs dos engenheiros do CSS SQL Server

• **White papers: **

  Guia de soluções AlwaysOn do Microsoft SQL Server para alta disponibilidade e recuperação de desastre

  White papers da Microsoft para SQL Server 2012

  White papers da equipe de consultoria do cliente do SQL Server

[Início]

Consulte também

Conceitos

Visão geral de grupos de disponibilidade AlwaysOn (SQL Server)

Modos de disponibilidade (grupos de disponibilidade AlwaysOn)

Failover e modos de failover (grupos de disponibilidade AlwaysOn)

Sobre Acesso de conexão de cliente a réplicas de disponibilidade (SQL Server)

Monitoramento de grupos de disponibilidade (SQL Server)

WSFC (Windows Server Failover Clustering) com o SQL Server