Compartilhar via

Link de failover – Instância Gerenciada de SQL do Azure

Applies to:Instância Gerenciada de SQL do Azure

Este artigo ensina como realizar failover de um banco de dados linked entre SQL Server e Instância Gerenciada de SQL do Azure usando o SQL Server Management Studio (SSMS) ou PowerShell, visando recuperação de desastres ou migração.

Pré-requisitos

Para fazer failover de bancos de dados para a réplica secundária por meio do link, é necessário ter os seguintes pré-requisitos:

Parar carga de trabalho

Caso esteja pronto para fazer failover do seu banco de dados para a réplica secundária, primeiro interrompa todas as cargas de trabalho de aplicativos na réplica primária durante suas horas de manutenção. Isso permite que a replicação de banco de dados alcance a réplica secundária para que você possa fazer failover para ela sem perda de dados. Garanta que seus aplicativos não estejam efetuando transações na primária antes do failover.

Verificar o atraso de replicação

É importante que a réplica secundária se sincronize com a réplica primária antes de executar um processo de failover planejado. O failover planejado pode expirar e falhar se a réplica secundária estiver significativamente atrasada em relação à réplica primária.

Use a seguinte consulta T-SQL em SQL Server e Instância Gerenciada de SQL para monitorar o atraso de replicação entre as réplicas:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Se o atraso de replicação for alto, aguarde até que a réplica secundária acompanhe a réplica primária. Talvez seja necessário executar etapas adicionais de solução de problemas se o atraso persistir, como melhorar a taxa de transferência de rede de vínculo entre as duas instâncias ou aumentar a capacidade do recurso na réplica secundária.

Fazer failover de um banco de dados

Você pode executar o failover de um banco de dados vinculado usando Transact-SQL (T-SQL), SQL Server Management Studio ou PowerShell.

Você pode realizar o failover do link usando Transact-SQL a partir do SQL Server 2022 CU13 (KB5036432).

Para executar um failover planejado de um link, use o seguinte comando T-SQL na réplica primária:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Para executar um failover forçado, use o comando T-SQL apresentado a seguir na réplica secundária:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Importante

Depois de executar um failover planejado, o modo de replicação é definido como assíncrono.

Fazer failover de vários bancos de dados

Se você planeja realizar failover de vários bancos de dados das instâncias no mesmo servidor, para garantir desempenho e previsibilidade ideais, realize o failover de 8 bancos de dados por instância por vez. Por exemplo, se você tiver 10 instâncias com 32 bancos de dados vinculados cada, faça failover de 8 bancos de dados por vez de cada instância e repita o processo até que todos os bancos de dados tenham failover.

Ver banco de dados após failover

Para SQL Server 2022, se optar por manter o link, verifique se o grupo de disponibilidade distribuído existe em Disponibilidade em Pesquisador de Objetos em SQL Server Management Studio.

Se você tiver descartado o link durante o failover, poderá usar Pesquisador de Objetos para confirmar se o grupo de disponibilidade distribuído não existe mais. Se você optar por manter o grupo de disponibilidade, o banco de dados ainda será Sincronizado.

Limpar após o failover

A menos que o link Remove após o failover bem-sucedido esteja selecionado, o failover com SQL Server 2022 não interromperá o link. Você pode manter o link após o failover, o que mantém o grupo de disponibilidade e o grupo de disponibilidade distribuído ativos. Nenhuma outra ação é necessária.

Descartar o link apenas descarta o grupo de disponibilidade distribuído e deixa o grupo de disponibilidade ativo. Você pode decidir manter o grupo de disponibilidade ou descartá-lo.

Se você decidir descartar seu grupo de disponibilidade, substitua o seguinte valor e execute o código de T-SQL de exemplo:

  • <AGName> com o nome do grupo de disponibilidade no SQL Server (usado para criar o link).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Estado inconsistente após failover forçado

Após um failover forçado, você pode encontrar um cenário de cérebro dividido em que ambas as réplicas estão na função principal, deixando o link em um estado inconsistente. Isso poderá acontecer se você realizar a transição para a réplica secundária durante um desastre e, em seguida, a réplica primária ficar online novamente.

Para resolver esse problema, confira Corrigir o cenário de divisão cerebral.

Conteúdo relacionado

Para usar o link:

Para saber mais sobre o link:

Para outros cenários de replicação e migração, considere:

  • Last updated on