Partilhar via

Ligação de failover - Instância Gerida do SQL Azure

Aplica-se a: Azure SQL Managed Instance

Este artigo ensina-lhe como realizar uma transição de falha numa base de dados ligada entre o SQL Server e o Azure SQL Managed Instance usando o SQL Server Management Studio (SSMS) ou PowerShell, com o intuito de recuperação em caso de desastre ou migração.

Pré-requisitos

Para fazer failover de seus bancos de dados para sua réplica secundária por meio do link, você precisa dos seguintes pré-requisitos:

Interromper a carga de trabalho

Se você estiver pronto para fazer failover do banco de dados para a réplica secundária, primeiro interrompa todas as cargas de trabalho do aplicativo na réplica principal durante o horário de manutenção. Isso permite que a replicação do banco de dados alcance o secundário para que você possa fazer failover para o secundário sem perda de dados. Certifique-se de que as suas aplicações não estão a confirmar transações para o primário antes de realizar o failover.

Verificar o atraso de replicação

É importante que a réplica secundária acompanhe a réplica primária antes de realizar um failover planeado. O failover planeado pode expirar e falhar se a réplica secundária ficar muito atrasada em relação à réplica primária.

Use a seguinte consulta T-SQL tanto no SQL Server como na SQL Managed Instance para monitorizar 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 elevado, espere que a réplica secundária alcance a réplica primária. Pode ser necessário realizar passos adicionais de resolução de problemas se o atraso persistir, como melhorar o throughput da rede de ligação entre as duas instâncias ou aumentar a capacidade de recursos na réplica secundária.

Alternância de um banco de dados

Pode fazer failover de uma base de dados vinculada usando Transact-SQL (T-SQL), SQL Server Management Studio ou PowerShell.

Pode alternar para o link usando Transact-SQL a partir do SQL Server 2022 CU13 (KB5036432).

Para executar um failover planejado para 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 seguinte comando T-SQL 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.

Fail sobre múltiplas bases de dados

Se planeia realizar failover de múltiplas bases de dados a partir de instâncias no mesmo servidor, para um desempenho ótimo e com previsibilidade, faça o failover de 8 bases de dados numa instância de cada vez. Por exemplo, se tiver 10 instâncias com 32 bases de dados ligadas cada uma, realize o failover de 8 bases de dados de cada vez por instância e repita o processo até que todas as bases de dados tenham sido submetidas a failover.

Exibir banco de dados após failover

Para SQL Server 2022, se optar por manter o link, pode verificar se o grupo de disponibilidade distribuída existe em Availability Groups em Object Explorer em SQL Server Management Studio.

Se perdeu o link durante o failover, pode usar Object Explorer para confirmar que o grupo de disponibilidade distribuída já não existe. Se você optar por manter o grupo de disponibilidade, o banco de dados ainda será sincronizado.

Limpeza após failover

A menos que Remover link após failover bem-sucedido esteja selecionado, o failover com SQL Server 2022 não quebra a ligação. Você pode manter o link após o failover, o que deixa o grupo de disponibilidade e o grupo de disponibilidade distribuída ativos. Não é necessária mais nenhuma ação.

Eliminar a ligação só remove o grupo de disponibilidade distribuído e mantém 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 T-SQL de exemplo:

  • <AGName> com o nome do grupo de disponibilidade em SQL Server (usado para criar a ligação).
-- 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 pode acontecer se você fizer failover para a réplica secundária durante um desastre e, em seguida, a réplica primária voltar a ficar online.

Para resolver esse problema, consulte Corrigir cenário de cérebro dividido.

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