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, o Transact-SQL ou o PowerShell no SQL Server. Um grupo de disponibilidade faz 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 primária. Paralelamente, o failover faz a transição da réplica primária antiga para a função secundária.

Um failover manual planejado é compatível apenas quando a réplica primária e a réplica secundária de destino estão executando no modo de confirmação síncrona e estão sincronizadas no momento. Um failover manual planejado preserva todos os dados nos bancos de dados secundários unidos no grupo de disponibilidade, na réplica secundária de destino. Depois que a réplica primária antiga faz a transição para a função secundária, seus bancos de dados tornam-se bancos de dados secundários. Em seguida, eles começam a sincronizar com os novos bancos de dados primários. Depois que a transição de todos é feita para o estado SYNCHRONIZED, a nova réplica secundária se torna qualificada para servir como o destino de uma futuro failover manual planejado.

Observação

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

Antes de começar

Importante

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

Limitações e restrições

Pré-requisitos e restrições

  • A réplica secundária de destino e a réplica primária devem estar executando em modo de disponibilidade de confirmação síncrona.

  • Nesse momento, a réplica secundária de destino deve estar sincronizada com a réplica primária. Todos os bancos de dados secundários nessa réplica secundária devem estar unidos no grupo de disponibilidade. Eles também devem estar sincronizados com os bancos de dados primários correspondentes (isto é, os bancos de dados secundários locais devem ser SINCRONIZADOS).

    Dica

    Para determinar a prontidão do failover de uma réplica secundária, consulte a coluna is_failover_ready na exibição de gerenciamento dinâmico sys.dm_hadr_database_replica_cluster_states. Como alternativa, você pode verificar a coluna Prontidão de Failover do painel do grupo Always On.

  • Esta tarefa tem suporte apenas na réplica secundária de destino. Você deve estar conectado à instância de 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, ALTER ANY AVAILABILITY GROUP ou CONTROL SERVER também é necessária.

Use SQL Server Management Studio.

Para fazer failover de um grupo de disponibilidade manualmente:

  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 precise ser submetido ao failover. Expanda a árvore de servidor.

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

  3. Clique com o botão direito do mouse no grupo de disponibilidade a ser submetido ao failover e selecione Failover.

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

Usar o Transact-SQL

Para fazer failover de um grupo de disponibilidade manualmente:

  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 AVAILABILITY GROUP group_name FAILOVER

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

    O exemplo a seguir faz failover manual do grupo de disponibilidade MyAg para a réplica secundária conectada:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Usar o PowerShell

Para fazer failover de um grupo de disponibilidade manualmente:

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

  2. Use 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, veja Obter ajuda do SQL Server PowerShell.

    O exemplo a seguir faz failover manual 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: após fazer failover manual de um grupo de disponibilidade

Se você tiver feito failover fora do conjunto de failover automático do grupo de disponibilidade, ajuste os votos de quorum dos nós de clustering de failover do Windows Server para refletir a nova configuração do grupo de disponibilidade. Para obter mais informações, veja WSFC (Clustering de Failover do Windows Server) com o SQL Server.

Fazer failover da réplica primária em um grupo de disponibilidade de 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 é a primária, faça failover. Em um grupo de disponibilidade típico, o gerenciador de cluster automatiza o processo de failover. Em um grupo de disponibilidade com o tipo de cluster 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

Failover 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 a instância que hospeda a réplica primária. Para evitar a perda potencial 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 atual primária e a de destino secundária do SYNCHRONOUS_COMMIT.

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

  2. Para identificar que as transações ativas foram confirmadas na réplica primária e em pelo menos uma réplica secundária síncrona, execute a consulta a seguir:

    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 script a seguir, substitua ag1 pelo nome do seu grupo de disponibilidade:

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

    Essa configuração garante que todas as transações ativas são confirmadas na réplica primária e em, pelo menos, uma réplica secundária síncrona.

    Observação

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

  4. Defina a réplica primária e as réplicas secundárias que não participam 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 a primária.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Atualize a função da réplica primária antiga e outras secundárias para SECONDARY e execute o seguinte comando na instância do SQL Server que hospeda 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 dado no grupo de disponibilidade da instância de SQL Server que hospeda a réplica primária:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Crie novamente qualquer ouvinte criado para fins de escala de leitura e que não seja gerenciado por um gerenciador de clusters. Se o ouvinte original apontar para a réplica primária antiga, descarte-o e crie-o novamente para apontar para a nova réplica 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, você precisará forçar um failover para a réplica secundária com perda de dados. No entanto, se a réplica primária original for recuperada após o failover, ela assumirá a função primária. Para evitar que cada réplica esteja em um estado diferente, remova a primária original do grupo de disponibilidade após um failover forçado com perda de dados. Quando a primária original voltar a ficar online, remova-a totalmente do grupo de disponibilidade.

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 do aplicativo é apontado para o ouvinte e/ou para a nova réplica primária.

  4. Se a primária original (N1) ficar online, use imediatamente o grupo de disponibilidade AGRScale offline na primária 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 de outras opções de replicação de dados que atendam às suas necessidades de negócios.

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

    DROP AVAILABILITY GROUP [AGRScale];

  7. Remova 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ê poderá adicionar a N1 de volta como uma nova réplica secundária ao grupo de disponibilidade AGRScale.

Confira também