Para fazer failover, primeiro você precisa alternar a instância do SQL Server nos modos de replicação usando Transact-SQL (T-SQL).
Em seguida, você pode realizar o failover e mudar funções usando o PowerShell.
Alterar modo de replicação (Failover para SQL MI)
A replicação entre o SQL Server e a Instância Gerenciada do SQL é assíncrona por padrão. Se você estiver fazendo failover do SQL Server para a Instância Gerenciada SQL do Azure, antes de fazer failover do banco de dados, alterne o link para o modo síncrono no SQL Server usando Transact-SQL (T-SQL).
Observação
- Ignore esta etapa se estiver fazendo failover da Instância Gerenciada do SQL para o SQL Server 2022.
- A replicação síncrona em grandes distâncias de rede pode tornar as transações mais lentas na réplica principal.
Execute o seguinte script T-SQL no SQL Server para alterar o modo de replicação do grupo de disponibilidade distribuída de assíncrono para sincronização. Substituir:
-
<DAGName> com o nome do grupo de disponibilidade distribuída (usado para criar o link).
-
<AGName> com o nome do grupo de disponibilidade criado no SQL Server (usado para criar o link).
-
<ManagedInstanceName> com o nome da instância gerenciada.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>]
MODIFY
AVAILABILITY GROUP ON
'<AGName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
'<ManagedInstanceName>' WITH
(AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
Para confirmar que você alterou o modo de replicação do link com êxito, use a seguinte exibição de gerenciamento dinâmico. Os resultados indicam o estado SYNCHRONOUS_COMMIT.
-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
ag.name, ag.is_distributed, ar.replica_server_name,
ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
ars.operational_state_desc, ars.synchronization_health_desc
FROM
sys.availability_groups ag
join sys.availability_replicas ar
on ag.group_id=ar.group_id
left join sys.dm_hadr_availability_replica_states ars
on ars.replica_id=ar.replica_id
WHERE
ag.is_distributed=1
Agora que você mudou o SQL Server para o modo de confirmação síncrona, a replicação entre as duas instâncias é síncrona. Se o utilizador precisar de reverter esse estado, siga as mesmas etapas e defina AVAILABILITY_MODE para ASYNCHRONOUS_COMMIT.
Verifique os valores de LSN no SQL Server e na Instância Gerenciada do SQL
Para concluir o failover ou a migração, confirme se a replicação para o sistema secundário foi concluída. Para isso, verifique se os números de sequência de log (LSNs) nos registros de log do SQL Server e da Instância Gerenciada do SQL são os mesmos.
Inicialmente, espera-se que o LSN no primário seja maior do que o LSN no secundário. A latência da rede pode fazer com que a replicação fique um pouco atrasada em relação à principal. Como a carga de trabalho foi interrompida no primário, as LSNs corresponderão e deixarão de mudar depois de algum tempo.
Use a seguinte consulta T-SQL no SQL Server para ler o LSN do último log de transações registrado. Substituir:
-
<DatabaseName> com o nome do banco de dados e procure o último número LSN protegido.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
ag.name AS [Replication group],
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
ag.is_distributed = 1 and db.name = '<DatabaseName>'
Use a seguinte consulta T-SQL na Instância Gerenciada SQL para ler o último LSN protegido para seu banco de dados. Substitua <DatabaseName> pelo nome do banco de dados.
Essa consulta funciona em uma instância gerenciada SQL de uso geral. Para uma Instância Gerida SQL Crítica para o Negócio, descomente and drs.is_primary_replica = 1 no final do script. Na camada de serviço Criticamente Importante para os Negócios, este filtro garante que os detalhes sejam lidos apenas da réplica principal.
-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
db.name AS [Database name],
drs.database_id AS [Database ID],
drs.group_id,
drs.replica_id,
drs.synchronization_state_desc AS [Sync state],
drs.end_of_log_lsn AS [End of log LSN],
drs.last_hardened_lsn AS [Last hardened LSN]
FROM
sys.dm_hadr_database_replica_states drs
inner join sys.databases db on db.database_id = drs.database_id
WHERE
db.name = '<DatabaseName>'
-- for Business Critical, add the following as well
-- AND drs.is_primary_replica = 1
Como alternativa, pode também usar o comando PowerShell Get-AzSqlInstanceLink ou o comando CLI do Azure az sql mi link show para obter a propriedade LastHardenedLsn do seu link na Instância Gerenciada SQL, fornecendo as mesmas informações que a consulta T-SQL anterior.
Importante
Verifique mais uma vez se sua carga de trabalho está parada no primário. Verifique se os LSNs no SQL Server e na Instância Gerenciada do SQL correspondem e se permanecem correspondentes e inalterados por algum tempo. LSNs estáveis em ambas as instâncias indicam que o log final foi replicado para o servidor secundário e a carga de trabalho foi realmente interrompida.
Alternância de um banco de dados
Se você quiser usar o PowerShell para fazer failover de um banco de dados entre o SQL Server 2022 e a Instância Gerenciada do SQL enquanto ainda mantém o link, ou para executar um failover com perda de dados para qualquer versão do SQL Server, use o assistente de Failover entre o SQL Server e a Instância Gerenciada no SSMS para gerar o script para seu ambiente. Você pode executar um failover planejado a partir da réplica primária ou secundária. Para fazer um failover forçado, conecte-se à réplica secundária.
Para quebrar o link e interromper a replicação quando você fizer failover ou migrar seu banco de dados, independentemente da versão do SQL Server, use o comando Remove-AzSqlInstanceLink PowerShell ou az sql mi link delete Azure CLI.
Atenção
- Antes de fazer failover, interrompa a carga de trabalho no banco de dados de origem para permitir que o banco de dados replicado recupere completamente e faça failover sem perda de dados. Se você executar um failover forçado ou quebrar o link antes da correspondência de LSNs, poderá perder dados.
- O failover de um banco de dados no SQL Server 2019 e versões anteriores quebra e remove o vínculo entre as duas réplicas. Você não pode voltar para a primária inicial.
O script de exemplo a seguir quebra o link e encerra a replicação entre suas réplicas, fazendo com que o banco de dados seja lido/gravado em ambas as instâncias. Substituir:
-
<ManagedInstanceName> com o nome da instância gerenciada.
-
<DAGName> com o nome do link que você está fazendo failover (saída da propriedade Name do Get-AzSqlInstanceLink comando executado anteriormente acima).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====
# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"
# ==== Do not customize the following cmdlet ====
# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force
Quando o failover é bem-sucedido, a conexão é perdida e não existe mais. O banco de dados do SQL Server e o banco de dados da Instância Gerenciada SQL podem executar cargas de trabalho de leitura/gravação, pois agora são completamente independentes.
Importante
Após o failover bem-sucedido para a Instância Gerenciada do SQL, reaponte manualmente a cadeia de conexão do(s) seu(s) aplicativo(s) para o FQDN da instância gerenciada do SQL para concluir o processo de migração ou failover e continuar em execução no Azure.
Depois que o link for descartado, você poderá manter o grupo de disponibilidade no SQL Server, mas deverá descartar o grupo de disponibilidade distribuído para remover metadados de link do SQL Server. Esta etapa adicional só é necessária ao fazer failover usando o PowerShell, já que o SSMS executa essa ação para você.
Para descartar seu grupo de disponibilidade distribuída, substitua o seguinte valor e execute o código T-SQL de exemplo:
-
<DAGName> com o nome do grupo de disponibilidade distribuído no SQL Server (usado para criar o link).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Azure SQL Managed Instance