Partilhar via

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

  • Artigo

Aplica-se a:SQL Server

Este tópico descreve como executar um failover manual sem perda de dados (um failover manual planejado) em um grupo de disponibilidade Always On usando o SQL Server Management Studio, Transact-SQL ou PowerShell no SQL Server. Um grupo de disponibilidade realiza failover no nível de uma réplica de disponibilidade. Um failover manual planejado, como qualquer failover de grupo de disponibilidade Always On, faz a transição de uma réplica secundária para a função principal. Ao mesmo tempo, o processo de failover faz a transição da antiga réplica primária para o papel secundário.

Um failover manual planeado é suportado apenas quando a réplica primária e a réplica secundária de destino estão a ser executadas no modo de confirmação síncrona e estão sincronizadas neste momento. O failover manual planejado preserva todos os dados nos bancos de dados secundários que estão associados ao grupo de disponibilidade na réplica secundária alvo. Depois que a réplica primária anterior transita para a função secundária, seus bancos de dados se tornam bancos de dados secundários. Em seguida, eles começam a sincronizar com os novos bancos de dados primários. Após todos transitarem para o estado SINCRONIZADO, a nova réplica secundária torna-se elegível para servir como o destino de um futuro failover manual planeado.

Observação

Se as réplicas secundária e primária estiverem configuradas para o modo de failover automático, depois que a réplica secundária for sincronizada, ela também poderá servir como destino para um failover automático. Para obter mais informações, consulte Modos de disponibilidade (grupos de disponibilidade Always On).

Antes de começar

Importante

Há procedimentos específicos para fazer failover de um grupo de disponibilidade em escala de leitura sem gerenciador de cluster. Quando um grupo de disponibilidade tiver CLUSTER_TYPE = NONE, siga os procedimentos em Failover da réplica primária em um grupo de disponibilidade em escala de leitura.

Limitações e restrições

Pré-requisitos e restrições

  • Tanto a réplica secundária de destino quanto a réplica primária devem estar em execução no modo de disponibilidade de confirmação sincronizada.

  • Atualmente, a réplica secundária de destino deve ser sincronizada com a réplica primária. Todos os bancos de dados secundários nessa réplica secundária devem ser associados ao grupo de disponibilidade. Eles também devem ser sincronizados com seus bancos de dados primários correspondentes (ou seja, os bancos de dados secundários locais devem ser SINCRONIZADOS).

    Dica

    Para determinar a prontidão para failover de uma réplica secundária, consulte a coluna is_failover_ready no modo de exibição de gerenciamento dinâmico sys.dm_hadr_database_replica_cluster_states. Ou pode examinar a coluna Preparação para Failover do painel do grupo Always On.

  • Esta tarefa é suportada apenas na réplica secundária de destino. Você deve estar conectado à instância do servidor que hospeda a réplica secundária de destino.

Segurança

Permissões

A permissão ALTER AVAILABILITY GROUP é necessária no grupo de disponibilidade. A permissão CONTROL AVAILABILITY GROUP, a permissão ALTER ANY AVAILABILITY GROUP ou a permissão CONTROL SERVER são também necessárias.

Usar o SQL Server Management Studio

Para fazer failover manual de um grupo de disponibilidade:

  1. No Pesquisador de Objetos, conecte-se a uma instância do servidor que hospeda uma réplica secundária do grupo de disponibilidade que precisa ser submetida a failover. Expanda a árvore do servidor.

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

  3. Clique com o botão direito do rato no grupo de disponibilidade que deve ser transferido e selecione Failover.

  4. O assistente de Grupo de Disponibilidade de Failover é iniciado. Para obter mais informações, consulte Utilizar o assistente do Grupo de Disponibilidade de Failover (SQL Server Management Studio).

Usar Transact-SQL

Para fazer failover manual de um grupo de disponibilidade:

  1. Conecte-se à instância do servidor que hospeda a réplica secundária de destino.

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

    ALTER O GRUPO DE DISPONIBILIDADE group_name FAILOVER

    Na declaração, group_name é o nome do grupo de disponibilidade.

    O exemplo a seguir realiza manualmente a transição do grupo de disponibilidade MyAg para a réplica secundária conectada.

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Usar o PowerShell

Para fazer failover manual de um grupo de disponibilidade:

  1. Altere o diretório (cd) para a instância do servidor que aloja a réplica secundária pretendida.

  2. Utilize o cmdlet Switch-SqlAvailabilityGroup.

    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 para o SQL Server PowerShell.

    O exemplo a seguir faz failover manualmente do grupo de disponibilidade MyAg para a réplica secundária com o caminho especificado:

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

    Para configurar e usar o provedor do SQL Server PowerShell:

Acompanhamento: Depois de fazer failover manualmente de um grupo de disponibilidade

Caso tenha comutado fora do conjunto de comutação automática do grupo de disponibilidade, ajuste os votos de quórum dos nós de cluster de comutação por falha do Windows Server para refletir a sua nova configuração do grupo de disponibilidade. Para mais informações, veja Windows Server Failover Clustering (WSFC) com o SQL Server.

Failover da réplica principal em um grupo de disponibilidade em escala de leitura

Cada grupo de disponibilidade tem apenas uma réplica primária. A réplica primária permite leituras e gravações. Para alterar qual réplica é primária, pode-se realizar um failover. Em um grupo de disponibilidade típico, o gerenciador de cluster automatiza o processo de failover. Em um grupo de disponibilidade com cluster tipo NONE, o processo de failover é manual.

Há duas maneiras de fazer failover da réplica primária em um grupo de disponibilidade com o tipo de cluster NONE:

  • Failover manual sem perda de dados
  • Failover manual forçado com perda de dados

Troca manual sem perda de dados

Use esse método quando a réplica primária estiver disponível, mas você precisará alterar temporária ou permanentemente qual instância hospeda a réplica primária. Para evitar possíveis perdas de dados, antes de emitir o failover manual, verifique se a réplica secundária de destino está atualizada.

Para fazer failover manualmente sem perda de dados:

  1. Torne a réplica primária atual na réplica secundária de destino SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Para identificar que as transações ativas estão comprometidas com a réplica primária e pelo menos uma réplica secundária síncrona, execute a seguinte consulta:

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    A réplica secundária é sincronizada quando synchronization_state_desc é SYNCHRONIZED.

  3. Atualize REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT para 1.

    O script a seguir define REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1 em um grupo de disponibilidade chamado ag1. Antes de executar o seguinte script, substituaag1 pelo nome do seu grupo de disponibilidade:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Essa configuração garante que cada transação ativa seja confirmada para a réplica primária e pelo menos uma réplica secundária síncrona.

    Observação

    Essa configuração não é específica para failover e deve ser definida com base nos requisitos do ambiente.

  4. Defina a réplica primária e a(s) réplica(s) secundária(s) que não participa(m) do failover offline para se prepararem para a alteração de função:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Promova a réplica secundária de destino para primária.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Por favor, atualize a função da réplica primária antiga e de outros secundários para SECONDARYe, em seguida, execute o seguinte comando na instância do SQL Server que aloca a réplica primária antiga:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Observação

    Para excluir um grupo de disponibilidade, use DROP AVAILABILITY GROUP. Para um grupo de disponibilidade criado com o tipo de cluster NONE ou EXTERNAL, execute o comando em todas as réplicas que fazem parte do grupo de disponibilidade.

  7. Retome a movimentação de dados, execute o seguinte comando para cada banco de dados no grupo de disponibilidade na instância do SQL Server que hospeda a réplica primária:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Recrie qualquer ouvinte criado para fins de escala de leitura e que não seja gerenciado por um gerenciador de cluster. Se o ouvinte original apontar para a primária antiga, solte-a e recrie-a para apontar para a nova primária.

Failover manual forçado com perda de dados

Se a réplica primária não estiver disponível e não puder ser recuperada imediatamente, será necessário forçar um failover para a réplica secundária com perda de dados. No entanto, se a réplica primária original se recuperar após o failover, ela assumirá a função principal. Para evitar que cada réplica esteja em um estado diferente, remova o primário original do grupo de disponibilidade após um failover forçado com perda de dados. Assim que o servidor principal original voltar a estar online, remova o grupo de disponibilidade por completo.

Para forçar um failover manual com perda de dados da réplica primária N1 para a réplica secundária N2, siga estas etapas:

  1. Na réplica secundária (N2), inicie o failover forçado:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Na nova réplica primária (N2), remova a primária original (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Valide se todo o tráfego da aplicação está direcionado para o listener e/ou para a nova réplica principal.

  4. Se o primário original (N1) voltar a estar online, coloque imediatamente offline o grupo de disponibilidade AGRScale no primário original (N1).

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Se houver dados ou alterações não sincronizadas, preserve esses dados por meio de backups ou outras opções de replicação de dados que atendam às suas necessidades de negócios.

  6. Em seguida, remova o grupo de disponibilidade do primário original (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Elimine o banco de dados do grupo de disponibilidade na réplica primária original (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Opcional) Se desejar, agora você pode adicionar N1 novamente como uma nova réplica secundária ao grupo de disponibilidade AGRScale.

Ver também