Executar um failover manual forçado de um Grupo de Disponibilidade Always On (SQL Server)

Aplica-se a:SQL Server

Este tópico 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 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ções será atrasado em um determinado banco de dados primário enquanto qualquer um de seus bancos de dados secundários esteja suspenso.

Importante

A sincronização de dados com o banco de dados primário não ocorrerá até o banco de dados secundário for retomado. Para obter informações sobre como retomar um banco de dados secundário, confira Acompanhamento: Tarefas essenciais após um failover forçado mais adiante neste artigo.

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 perda de dados após quorum forçadomais adiante 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 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 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 um failover e para obter um cenário de exemplo que usa um failover forçado para recuperação de uma falha catastrófica, confira Cenário de exemplo: Usando um failover forçado para recuperação de uma falha catastrófica, mais adiante neste tópico.

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, o failover forçado causará uma falha na inicialização do banco de dados como um banco de dados primário. Se o banco de dados estiver no estado INITIALIZING, você precisará aplicar os registros de log ausentes de um backup de banco de dados ou restaurar completamente o banco de dados 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 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, confira Transações entre bancos de dados e transações distribuídas para espelhamento de banco de dados e grupos de disponibilidade Always On (SQL Server).

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

• É 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 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 está no estado INITIALIZING ou REVERTING, confira 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 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 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 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ê 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 quórum 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 quórum 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 será marcado como sincronizado no cluster e não estará 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, confira “Controlando a potencial 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.

Como usar o SQL Server Management Studio.

Para forçar o 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, 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, confira Acompanhamento: Tarefas essenciais após um failover forçado, mais adiante neste tópico.

Usando o Transact-SQL

Para forçar o 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 passar por failover.

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

   ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   em que 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, confira Acompanhamento: Tarefas essenciais após um failover forçado, mais adiante neste tópico.

Usando o PowerShell

Para forçar o 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 passar por failover.

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

   • -AllowDataLoss

     Por padrão, o parâmetro -AllowDataLoss faz com que o Switch-SqlAvailabilityGroup avise a você que o failover forçado pode resultar na perda de transações não confirmadas e solicite uma confirmação. 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 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 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, confira Acompanhamento: Tarefas essenciais após um failover forçado, mais adiante neste tópico.

Para configurar e usar o provedor do SQL Server PowerShell

• Provedor do SQL Server PowerShell

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

     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 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 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ários de 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 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 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 (SQL Server)

Cenário de exemplo: usando 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 que são necessárias para usar um failover forçado para recuperar-se 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ó 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 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) (Consultar a coluna end_of_log_lsn. Para obter mais informações, confira Recomendações, anteriormente neste tópico.)
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)

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 reiniciarem, eles poderão formar um novo quorum se as duas condições a seguir existirem: (a) 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 o quorum para criar um conjunto de quorum minoritário, confira Recuperação de desastres do 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 de 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ções é 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: 1) Altere uma réplica de disponibilidade offline para o modo de confirmação assíncrona. 2) Altere 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) Usar 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: 1) Altera a réplica primária antiga (no centro remoto) de volta para o modo de confirmação assíncrona. 2) 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)

Related Tasks

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

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)

Conteúdo relacionado

• Blogs:

  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

• Whitepapers:

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

  • White papers da equipe de consultoria do cliente do SQL Server

Consulte Também

Visão geral dos 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