Share via

Configure um link com scripts - Instância Gerenciada de SQL do Azure

  • Artigo

Aplica-se a:Instância Gerenciada de SQL do Azure

Este artigo ensina como configurar um link entre o SQL Server e a Instância Gerenciada de SQL do Azure com scripts Transact-SQL e PowerShell ou CLI do Azure. Com o link, os bancos de dados da primária inicial são replicados para a réplica secundária quase em tempo real.

Depois que o link for criado, é possível fazer failover para a réplica secundária para fins de migração ou recuperação de desastre.

Observação

Visão geral

Use o recurso de link para replicar bancos de dados da primária inicial para a réplica secundária. Para o SQL Server 2022, a primária inicial pode ser o SQL Server ou a Instância Gerenciada de SQL do Azure. Para o SQL Server 2019 e versões anteriores, a primária inicial deve ser o SQL Server. Depois que o link é configurado, os bancos de dados da primária inicial são replicados para a réplica secundária.

É possível optar por deixar o link no lugar para replicação contínua de dados em um ambiente híbrido entre a réplica primária e secundária, ou fazer o failover do banco de dados para a réplica secundária, para migrar para o Azure ou para recuperação de desastre. Para o SQL Server 2019 e versões anteriores, fazer failover para a Instância Gerenciada de SQL do Azure quebra o link. Assim, a operação de failback não tem suporte. Com o SQL Server 2022, é possível optar por manter o link e fazer failover de ida e volta entre as duas réplicas. Esse recurso está atualmente em versão prévia.

Se planejar utilizar a instância gerenciada secundária apenas para recuperação de desastre, é possível economizar em custos de licenciamento ativando o benefício de failover híbrido.

Utilize as instruções neste artigo para configurar manualmente o link entre o SQL Server e a Instância Gerenciada de SQL do Azure. Após a criação do link, o banco de dados de origem recebe uma cópia somente leitura na réplica secundária de destino.

Dica

  • Para simplificar o uso de scripts T-SQL com os parâmetros corretos para seu ambiente, é altamente recomendável usar o assistente de link Instância Gerenciada no SSMS (SQL Server Management Studio) para gerar um script para criar o link. Na página Resumo da janela Novo link Instância Gerenciada, selecione Script em vez de Concluir.

Pré-requisitos

Observação

Algumas funcionalidades do link estão em disponibilidade geral, enquanto outras estão atualmente em versão prévia. Revise a compatibilidade de versões para obter mais informações.

Para replicar seus bancos de dados, você precisa dos seguintes pré-requisitos:

Considere o seguinte:

  • O recurso de link suporta um banco de dados por link. Para replicar bancos de dados múltiplos em uma instância, crie um link para cada banco de dados individual. Por exemplo, para replicar 10 bancos de dados para a Instância Gerenciada SQL, crie 10 links individuais.
  • O agrupamento entre o SQL Server e a Instância Gerenciada do SQL deve ser o mesmo. Uma incompatibilidade no agrupamento pode causar uma incompatibilidade na caixa de nome do servidor e impedir uma conexão bem-sucedida do SQL Server com a Instância Gerenciada de SQL.
  • O erro 1475 no SQL Server primário inicial indica que é necessário iniciar uma nova cadeia de backup, criando um backup completo sem a COPY ONLY opção.

Permissões

No SQL Server, você deve ter permissões sysadmin.

Na Instância Gerenciada de SQL do Azure, você deve ser membro do Colaborador de Instância Gerenciada de SQL ou ter as seguintes permissões para uma função personalizada:

Recurso Microsoft.Sql/ Permissões necessárias
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologia e convenções de nomenclatura

À medida que você executa scripts deste guia do usuário, é importante não confundir nomes de SQL Server e Instância Gerenciada SQL com seus nomes de domínio totalmente qualificados (FQDNs). A tabela a seguir explica o que os vários nomes representam exatamente e como obter seus valores:

Terminologia Descrição Como descobrir
Primário inicial 1 O SQL Server ou a Instância Gerenciada de SQL em que você cria inicialmente o link para replicar o banco de dados para a réplica secundária.
Réplica primária O SQL Server ou a Instância Gerenciada de SQL que atualmente hospeda o banco de dados primário.
Réplica secundária O SQL Server ou a Instância Gerenciada de SQL que está recebendo dados replicados quase em tempo real da réplica primária atual.
Nome do SQL Server Nome curto com uma só palavra do SQL Server. Por exemplo: sqlserver1 . Executar SELECT @@SERVERNAME do T-SQL.
FQDN do SQL Server FQDN (nome de domínio totalmente qualificado) do SQL Server. Por exemplo: "sqlserver1.domain.com". Consulte sua configuração de rede (DNS) local ou o nome do servidor se estiver usando uma máquina virtual (VM) do Azure.
Nome da Instância Gerenciada de SQL Nome curto com uma só palavra da Instância Gerenciada de SQL. Por exemplo: "managedinstance1". Confira o nome da sua instância gerenciada no portal do Azure.
FQDN da Instância Gerenciada de SQL FQDN (nome de domínio totalmente qualificado) da Instância Gerenciada de SQL. Por exemplo: "managedinstance1.6d710bcf372b.database.windows.net". Consulte o nome do anfitrião na página de visão geral da Instância Gerenciada de SQL no portal do Azure.
Nome de domínio resolvível Nome DNS que pode ser resolvido para um endereço IP. Por exemplo, a execução de nslookup sqlserver1.domain.com retorna um endereço IP, como 10.0.0.1. Execute o comando nslookup no prompt de comando.
IP do SQL Server Endereço IP do SQL Server. No caso de vários IPs no SQL Server, escolha um endereço IP que possa ser acessado no Azure. Execute o comando ipconfig no prompt de comando do sistema operacional host que executa o SQL Server.

1 A configuração da Instância Gerenciada de SQL do Azure como sua primária inicial está atualmente em prévia e só tem suporte a partir do SQL Server 2022 CU10.

Configurar recuperação e backup de banco de dados

Se o SQL Server for o seu primário inicial, os bancos de dados que serão replicados por meio do link devem estar no modelo de recuperação completa e ter pelo menos um backup. Como a Instância Gerenciada de SQL do Azure faz backups de forma automática, é possível ignorar esta etapa se a Instância Gerenciada de SQL for a primária inicial. primary

Execute o código a seguir no SQL Server para todos os bancos de dados que você deseja replicar. Substitua <DatabaseName> pelo nome atual do banco de dados.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Para saber mais, confira Criar um backup completo de banco de dados.

Observação

O link dá suporte apenas à replicação de bancos de dados de usuário. Não há suporte para a replicação de bancos de dados do sistema. Para replicar objetos em nível de instância (armazenados em bancos de dados master ou msdb), recomendamos que você faça o script deles e execute scripts T-SQL na instância de destino.

Estabelecer confiança entre instâncias

Primeiro, é necessário estabelecer confiança entre as duas instâncias e garantir a segurança dos pontos de extremidade usados para comunicar e criptografar dados pela rede. Os grupos de disponibilidade distribuídos usam o ponto de extremidade de espelhamento de banco de dados do grupo de disponibilidade existente, em vez de ter um ponto de extremidade dedicado próprio. Como tal, a segurança e a confiança precisam ser configuradas entre as duas instâncias por meio do ponto de extremidade de espelhamento de banco de dados do grupo de disponibilidade.

Observação

O link é baseado na tecnologia do grupo de disponibilidade Always On. O ponto de extremidade de espelhamento de banco de dados é um ponto de extremidade com finalidade especial usado exclusivamente pelo grupo de disponibilidade para receber conexões de outras instâncias. O termo "ponto de extremidade de espelhamento de banco de dados" não deve ser confundido com o recurso herdado de espelhamento de banco de dados do SQL Server.

A confiança baseada em certificado é a única maneira suportada para proteger pontos de extremidade de espelhamento de banco de dados para o SQL Server e na Instância Gerenciada do SQL. Se você tiver grupos de disponibilidade existentes que usam autenticação do Windows, você precisará adicionar a confiança baseada em certificado ao ponto de extremidade de espelhamento existente como uma opção de autenticação secundária. Faça isso usando a instrução ALTER ENDPOINT, conforme mostrado mais adiante neste artigo.

Importante

Os certificados são gerados com data e hora de expiração. Eles precisam ser renovados e girados antes da validade.

A seguir, esta é a visão geral do processo para proteger os pontos de extremidade de espelhamento de banco de dados para SQL Server e Instância Gerenciada de SQL:

  1. Gere um certificado no SQL Server e obtenha sua chave pública.
  2. Obtenha a chave pública do certificado da Instância Gerenciada do SQL.
  3. Troque as chaves públicas entre o SQL Server e a Instância Gerenciada de SQL.
  4. Importar chaves de autoridade de certificado raiz confiável do Azure para o SQL Server

As seções a seguir descrevem essas etapas com detalhes.

Crie um certificado no SQL Server e importe sua chave pública para a Instância Gerenciada

Primeiro, crie a chave mestra do banco de dados no banco de dados master, se ela ainda não estiver presente. Insira sua senha no lugar de <strong_password> no script a seguir e guarde-a em um lugar confidencial e seguro. Execute este script T-SQL no SQL Server:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Em seguida, gere um certificado de autenticação no SQL Server. No script a seguir, substitua:

  • @cert_expiry_date pela data de validade do certificado desejada (data futura).

Registre essa data e defina um lembrete para girar (atualizar) o certificado do SQL Server antes da expiração para garantir a operação contínua do link.

Importante

É altamente recomendável usar o nome do certificado gerado automaticamente por meio desse script. Embora a personalização do seu nome de certificado no SQL Server seja permitida, o nome não deve conter nenhum caractere \.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

Em seguida, use a seguinte consulta T-SQL no SQL Server para verificar se o certificado foi criado:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Nos resultados da consulta, você verá que o certificado foi criptografado com a chave mestra.

Agora você pode obter a chave pública do certificado gerado no SQL Server:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Salve os valores de SQLServerCertName e de SQLServerPublicKey na saída, porque você precisará deles na próxima etapa ao importar o certificado.

Primeiro, verifique se você está conectado ao Azure e se selecionou a assinatura em que a instância gerenciada está hospedada. A seleção da assinatura correta é especialmente importante se você tem mais de uma assinatura do Azure na conta.

Substitua <SubscriptionID> por sua ID da assinatura do Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Em seguida, use o comando New-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert create do CLI do Azure para fazer o upload da chave pública do certificado de autenticação do SQL Server para o Azure, como o exemplo de PowerShell a seguir.

Preencha as informações necessárias do usuário, copie-as, cole-as e execute o script. Substitua:

  • <SQLServerPublicKey> pela parte pública do certificado do SQL Server em formato binário, que você registrou na etapa anterior. É um valor de cadeia longo que começa com 0x.
  • <SQLServerCertName> pelo nome do certificado do SQL Server que você registrou na etapa anterior.
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

O resultado dessa operação é um resumo do certificado do SQL Server carregado no Azure.

Se precisar ver todos os certificados do SQL Server carregados para uma instância gerenciada, use o comando Get-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert list da CLI do Azure no Azure Cloud Shell. Para remover um certificado do SQL Server carregado em uma instância gerenciada, use o comando Remove-AzSqlInstanceServerTrustCertificate do PowerShell ou o comando az sql mi partner-cert delete da CLI do Azure no Azure Cloud Shell.

Obtenha a chave pública do certificado da Instância Gerenciada do SQL e importe-a para o SQL Server

O certificado para proteger o ponto de extremidade do link é gerado automaticamente na Instância Gerenciada de SQL do Azure. Obtenha a chave pública do certificado da Instância Gerenciada de SQL e importe-a para o SQL Server usando o comando Get-AzSqlInstanceEndpointCertificate do PowerShell ou o comando az sql mi endpoint-cert show da CLI do Azure, como no exemplo de PowerShell a seguir.

Cuidado

Ao usar a CLI do Azure, você precisará adicionar manualmente 0x à frente da saída PublicKey ao usá-la nas etapas subsequentes. Por exemplo, a PublicKey será semelhante a "0x3082033E30...".

Execute o seguinte script. Substitua:

  • <SubscriptionID> com sua ID de assinatura do Azure.
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Copie toda a saída de PublicKey (começa com 0x), pois você precisará dela na próxima etapa.

Como alternativa, se você encontrar problemas ao copiar e colar a PublicKey, execute também o comando EXEC sp_get_endpoint_certificate 4 T-SQL na instância gerenciada para obter a chave pública para o ponto de extremidade do link.

Em seguida, importe a chave pública obtida do certificado de segurança da instância gerenciada para o SQL Server. Execute a consulta a seguir no SQL Server. Substitua:

  • <ManagedInstanceFQDN> pelo nome de domínio totalmente qualificado da instância gerenciada.
  • <PublicKey> pelo valor da PublicKey obtido na etapa anterior (do Azure Cloud Shell, começando com 0x). Você não precisa usar aspas.

Importante

O nome do certificado precisa ser o FQDN da Instância Gerenciada de SQL e não deve ser modificado. O link não funcionará se você estiver usando um nome personalizado.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Importar chaves de autoridade de certificado raiz confiável do Azure para o SQL Server

A importação de chaves públicas de certificado raiz das ACs (autoridades de certificação) Microsoft e DigiCert para o SQL Server é necessária para o SQL Server a fim de confiar nos certificados emitidos pelo Azure para os domínios database.windows.net.

Cuidado

Verifique se a PublicKey começa com um 0x. Talvez seja necessário adicioná-lo manualmente ao início do PublicKey se ele ainda não estiver lá.

Primeiro, importe o certificado de autoridade raiz do PKI da Microsoft no SQL Server:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exsits.'
GO

Em seguida, importe o certificado de autoridade raiz do PKI da DigiCert no SQL Server:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exsits.'
GO

Por fim, verifique todos os certificados criados usando a seguinte visualização de gerenciamento dinâmico (DMV):

-- Run on SQL Server
SELECT * FROM sys.certificates

Proteger o ponto de extremidade de espelhamento de banco de dados

Se você não tiver um grupo de disponibilidade existente nem um ponto de extremidade de espelhamento de banco de dados no SQL Server, a próxima etapa será criar um ponto de extremidade de espelhamento de banco de dados no SQL Server e protegê-lo com o certificado do SQL Server gerado anteriormente. Se você tiver um grupo de disponibilidade ou ponto de extremidade de espelhamento existente, vá direto para a seção Alterar um ponto de extremidade existente.

Criar e proteger o ponto de extremidade de espelhamento de banco de dados no SQL Server

Para verificar se você não tem um ponto de extremidade de espelhamento de banco de dados existente criado, use o seguinte script:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Se a consulta anterior não mostrar um ponto de extremidade de espelhamento de banco de dados existente, execute o script a seguir no SQL Server para obter o nome do certificado do SQL Server gerado anteriormente.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Salve SQLServerCertName na saída, pois você precisará dele na próxima etapa.

Use o script a seguir para criar um ponto de extremidade de espelhamento de banco de dados na porta 5022 e proteger o ponto de extremidade com o certificado do SQL Server. Substitua:

  • <SQL_SERVER_CERTIFICATE> pelo nome do SQLServerCertName obtido na etapa anterior.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Valide se o ponto de extremidade de espelhamento foi criado executando o seguinte script no SQL Server:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

A coluna state_desc do ponto de extremidade criado com sucesso indicará STARTED.

Um novo ponto de extremidade de espelhamento foi criado com autenticação de certificado e criptografia AES habilitada.

Alterar um ponto de extremidade existente

Observação

Ignore esta etapa se você acabou de criar um novo ponto de extremidade de espelhamento. Use esta etapa somente se estiver usando grupos de disponibilidade existentes com um ponto de extremidade de espelhamento de banco de dados existente.

Se você estiver usando grupos de disponibilidade existentes para o link ou se houver um ponto de extremidade de espelhamento de banco de dados existente, primeiro valide se ele atende às seguintes condições obrigatórias para o link:

  • O tipo deve ser DATABASE_MIRRORING.
  • A autenticação de conexão deve ser CERTIFICATE.
  • A criptografia deve estar habilitada.
  • O algoritmo de criptografia deve ser AES.

Execute a consulta a seguir no SQL Server para exibir os detalhes de um ponto de extremidade de espelhamento de banco de dados existente:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Se a saída mostrar que o DATABASE_MIRRORING ponto de extremidade existente connection_auth_descnão é CERTIFICATE ou encryption_algorthm_descnão éAES, o ponto de extremidade precisará ser alterado para atender aos requisitos.

No SQL Server, o mesmo ponto de extremidade de espelhamento de banco de dados é usado para grupos de disponibilidade e grupos de disponibilidade distribuídos. connection_auth_descSe o ponto de extremidade for NTLM(autenticação do Windows) ou KERBEROS, e você precisar de autenticação do Windows para um grupo de disponibilidade existente, será possível alterar o ponto de extremidade para usar vários métodos de autenticação alternando a opção de autenticação para NEGOTIATE CERTIFICATE. Isso permite que o grupo de disponibilidade existente use a autenticação do Windows, enquanto usa a autenticação de certificado para a Instância Gerenciada de SQL.

Da mesma forma, se a criptografia não incluir AES e você precisar de criptografia RC4, é possível alterar o ponto de extremidade para usar ambos os algoritmos. Para obter detalhes sobre as possíveis opções para alterar pontos de extremidade, consulte a página de documentação para sys.database_mirroring_endpoints.

O script a seguir é um exemplo de como alterar seu ponto de extremidade de espelhamento de banco de dados existente no SQL Server. Substitua:

  • <YourExistingEndpointName> pelo nome do ponto de extremidade existente.
  • <SQLServerCertName> pelo nome do certificado do SQL Server gerado (obtido em uma das etapas anteriores acima).

Dependendo de sua configuração específica, talvez seja necessário personalizar ainda mais o script. Você também pode usar SELECT * FROM sys.certificates para obter o nome do certificado criado no SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Depois de executar a ALTER consulta de ponto de extremidade e definir o modo de autenticação dupla para Windows e certificado, use essa consulta novamente no SQL Server para mostrar detalhes do ponto de extremidade de espelhamento de banco de dados:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Você modificou com êxito seu ponto de extremidade de espelhamento de banco de dados para um link de instância gerenciada de SQL.

Criar um grupo de disponibilidade no SQL Server

Se você não tiver um grupo de disponibilidade existente, a próxima etapa é criar um no SQL Server, independente de qual será o primário inicial. Os comandos para criar o grupo de disponibilidade são diferentes se a Instância Gerenciada de SQL for o primário inicial, que só terá suporte a partir do SQL Server 2022 CU10.

Embora seja possível estabelecer vários links para o mesmo banco de dados, o link oferece suporte apenas à replicação de um banco de dados por link. Se desejar criar vários links para o mesmo banco de dados, use o mesmo grupo de disponibilidade para todos os links, mas crie um novo grupo de disponibilidade distribuído para cada link de banco de dados entre o SQL Server e a Instância Gerenciada de SQL.

Se o SQL Server for o principal inicial, crie um grupo de disponibilidade com os seguintes parâmetros para um link:

  • Nome do servidor primário inicial
  • Nome do banco de dados
  • Um modo de failover de MANUAL
  • Um modo de semeadura AUTOMATIC

Primeiro, descubra o nome do seu SQL Server executando a seguinte instrução T-SQL:

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

Em seguida, use o script a seguir para criar o grupo de disponibilidade no SQL Server. Substitua:

  • <AGName>com o nome do seu grupo de disponibilidade. Um link de Instância Gerenciada requer um banco de dados por grupo de disponibilidade. Para vários bancos de dados, você precisará criar vários grupos de disponibilidade. Considere nomear cada grupo de disponibilidade para que seu nome reflita o banco de dados correspondente - por exemplo, AG_<db_name>.
  • <DatabaseName> pelo nome do banco de dados que você deseja replicar.
  • <SQLServerName> pelo nome da instância do SQL Server obtido na etapa anterior.
  • <SQLServerIP> com o endereço IP do SQL Server. Você pode usar um nome de máquina host do SQL Server que pode ser resolvido como alternativa, mas você precisa se certificar de que o nome pode ser resolvido na rede virtual da Instância Gerenciada do SQL.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Importante

Para o SQL Server 2016, exclua WITH (CLUSTER_TYPE = NONE) da instrução T-SQL acima. Mantenha-o no estado em que se encontra em todas as versões posteriores do SQL Server.

Em seguida, crie o grupo de disponibilidade distribuído no SQL Server. Se você planeja criar vários links, precisará criar um grupo de disponibilidade distribuído para cada link, mesmo que esteja estabelecendo vários links para o mesmo banco de dados.

Substitua os valores a seguir e execute o script T-SQL para criar seu grupo de disponibilidade distribuído.

  • <DAGName> pelo nome do seu grupo de disponibilidade distribuído. Como é possível configurar vários links para o mesmo banco de dados criando um grupo de disponibilidade distribuído para cada link, considere nomear cada grupo de disponibilidade distribuída de acordo, por exemplo, DAG1_<db_name>, DAG2_<db_name>.
  • <AGName> com o nome do grupo de disponibilidade que você criou na etapa anterior.
  • <SQLServerIP> com o endereço IP do SQL Server da etapa anterior. Você pode usar um nome de computador host do SQL Server como alternativa, mas garanta que o nome possa ser resolvido na rede virtual da Instância Gerenciada de SQL (que exige a configuração de um DNS do Azure personalizado para a sub-rede da instância gerenciada).
  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
  • <ManagedInstanceFQDN> com o nome de domínio totalmente qualificado da sua instância gerenciada.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Verificar grupos de disponibilidade

Use o script a seguir para listar todos os Grupos de disponibilidade e grupos de disponibilidade distribuídos na instância do SQL Server. Neste ponto, o estado do seu grupo de disponibilidade precisa ser connected, e o estado de seus grupos de disponibilidade distribuídos precisa ser disconnected. O estado do Grupo de Disponibilidade Distribuído muda para connected uma vez que tiver sido ingressado na Instância Gerenciada SQL.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Como alternativa, você pode usar o SSMS Pesquisador de Objetos para localizar grupos de disponibilidade e grupos de disponibilidade distribuídos. Expanda a pasta Always On High Availability e, em seguida, a pasta Grupos de Disponibilidade.

Por fim, você pode criar o link. Os comandos diferem com base em qual instância é o primário inicial. Use o comando New-AzSqlInstanceLink do PowerShell ou o comando az sql mi link create da CLI do Azure para criar o link, como no exemplo de PowerShell nesta seção. No momento, não há suporte para a criação do link a partir de um primário da Instância Gerenciada de SQL com a CLI do Azure.

Se você precisar ver todos os links em uma instância gerenciada, use o comando Get-AzSqlInstanceLink do PowerShell ou o comando az sql mi link show da CLI do Azure no Azure Cloud Shell.

Para simplificar o processo, entre no portal do Azure e execute o script do Azure Cloud Shell a seguir. Substitua:

  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
  • <AGName> pelo nome do grupo de disponibilidade criado no SQL Server.
  • <DAGName> pelo nome do grupo de disponibilidade distribuído criado no SQL Server.
  • <DatabaseName> pelo banco de dados replicado no grupo de disponibilidade no SQL Server.
  • <SQLServerIP> pelo endereço IP do SQL Server. O endereço IP fornecido precisa ser acessível para a instância gerenciada.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

O resultado dessa operação é um carimbo de data/hora da execução bem-sucedida da solicitação para criar um link.

Para verificar a conexão entre a Instância Gerenciada de SQL e o SQL Server, execute a consulta a seguir no SQL Server. A conexão não será instantânea. Pode levar até um minuto para que a DMV comece a mostrar uma conexão bem-sucedida. Continue atualizando a DMV até que a conexão seja exibida como CONNECTED para a réplica da Instância Gerenciada de SQL.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Depois que a conexão é estabelecida, o Pesquisador de Objetos no SSMS pode inicialmente mostrar os bancos de dados na réplica secundária em estado de Restauração à medida que a fase de propagação inicial se move e restaura o backup completo do banco de dados. Depois que o banco de dados é restaurado, a replicação precisa ser recuperada para colocar os dois bancos de dados em um estado sincronizado. O banco de dados não estará mais em Restauração depois que a propagação inicial terminar. A propagação de bancos de dados pequenos pode ser rápida o suficiente para que você não veja o estado inicial de Restauração no SSMS.

Importante

  • O link não funcionará a menos que exista conectividade de rede entre o SQL Server e a Instância Gerenciada SQL. Para solucionar problemas de conectividade de rede, siga as etapas em Testar conectividade de rede.
  • Faça backups regulares do arquivo de log no SQL Server. Se o espaço de log usado atingir 100%, a replicação para Instância Gerenciada de SQL será interrompida até que o uso de espaço seja reduzido. É altamente recomendável automatizar os backups de log configurando um trabalho diário. Para obter detalhes, consulte Fazer o back-up de arquivos de log SQL Server.

Parar carga de trabalho

Para fazer failover do banco de dados para a réplica secundária, primeiro pare todas as cargas de trabalho de aplicativos no primário durante as horas de manutenção. Isso permite que a replicação de banco de dados alcance a réplica secundária para que você possa migrar ou fazer failover para o Azure sem perda de dados. Embora o banco de dados primário faça parte de um grupo de disponibilidade Always On, não é possível defini-lo como modo somente leitura. É necessário garantir que os aplicativos não estejam confirmando transações na réplica primária antes do failover.

Alternar o modo de replicação

A replicação entre SQL Server e SQL Instância Gerenciada é assíncrona por padrão. Antes de fazer failover do seu banco de dados para a secundária, alterne o link para o modo síncrono. A replicação síncrona entre grandes distâncias de rede pode retardar as transações na réplica primária.

Alternar do modo assíncrono para o modo síncrono exige uma alteração no modo de replicação na Instância Gerenciada de SQL e no SQL Server.

Alternar o modo de replicação (Instância Gerenciada de SQL)

Use o Azure PowerShell ou a CLI do Azure para alternar o modo de replicação em Instância Gerenciada de SQL.

Primeiro, verifique se você está conectado ao Azure e se selecionou a assinatura em que a instância gerenciada está hospedada, utilizando o comando Select-AzSubscription do PowerShell ou o comando az account set da CLI do Azure. A seleção da assinatura correta é especialmente importante se você tem mais de uma assinatura do Azure na conta.

No exemplo de PowerShell a seguir, substitua <SubscriptionID> pelo ID da sua assinatura do Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Saiba o nome do link que você deseja passar por failover. Você pode usar o comando Get-AzSqlInstanceLink do PowerShell ou o comando az sql mi link list da CLI do Azure.

Use o seguinte script do PowerShell para listar todos os links ativos na Instância Gerenciada de SQL. Substitua <ManagedInstanceName> pelo nome curto da instância gerenciada.

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

Na saída do script anterior, registre a propriedade Name do link que você deseja fazer failover.

Em seguida, alterne o modo de replicação de assíncrono para síncrono na Instância Gerenciada de SQL para o link identificado, usando o comando Update-AzSqlInstanceLink do PowerShell ou o comando az sql mi link update da CLI do Azure.

No exemplo de PowerShell a seguir, substitua:

  • <ManagedInstanceName> com o nome abreviado de sua instância gerenciada.
  • <DAGName> com o nome do link descoberto na etapa anterior (a propriedade Name da etapa anterior).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

# Enter your managed instance name – for example, "sqlmi1" 
$ManagedInstanceName = "<ManagedInstanceName>" 

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

O comando anterior indica sucesso exibindo um resumo da operação, com a propriedade ReplicationMode mostrada como Sync.

Se precisar reverter a operação, execute o script anterior para alternar o modo de replicação mas substitua a cadeia de caracteres Sync em -ReplicationMode para Async.

Alternar o modo de replicação (SQL Server)

Use o script T-SQL a seguir no SQL Server para alterar o modo de replicação do grupo de disponibilidade distribuído no SQL Server de assíncrono para síncrono. Substitua:

  • <DAGName> com o nome do grupo de disponibilidade distribuído (usado para criar o link).
  • <AGName> com o nome do grupo de disponibilidade criado no SQL Server (usado para criar o link).
  • <ManagedInstanceName> pelo 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 se você alterou o modo de replicação do link com êxito, use a exibição de gerenciamento dinâmico a seguir. Os resultados indicam o estado SYNCHRONOUS_COMIT.

-- 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ê alternou a Instância Gerenciada de SQL e o SQL Server para o modo síncrono, replicação entre as duas instâncias é síncrona. Caso precise reverter esse estado, siga as mesmas etapas e defina o estado asyncpara o SQL Server e a Instância Gerenciada de SQL.

Verificar os valores de LSN no SQL Server e na Instância Gerenciada de SQL

Para finalizar o failover ou a migração, confirme se a replicação foi concluída. Para isso, você precisa verificar os LSNs (números de sequência de log) nos registros de log para o SQL Server e a Instância Gerenciada de SQL são iguais.

Inicialmente, espera-se que os LSN na primária seja maior do que os LSN na secundária. A latência da rede pode fazer com que a replicação fique um pouco atrás do primário. Como a carga de trabalho foi interrompida no primário, você deve esperar que os LSNs sejam correspondentes e parem de mudar após algum tempo.

Use a consulta T-SQL a seguir no SQL Server para ler o LSN do último log de transações gravado. Substitua:

  • <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 consulta T-SQL a seguir na Instância Gerenciada de SQL para ler o último LSN protegido do banco de dados. Substitua <DatabaseName> pelo nome do Banco de Dados SQL.

Essa consulta funciona em uma Instância Gerenciada de SQL de Uso Geral. Para a Instância Gerenciada de SQL Comercialmente Crítica, você precisará remover o comentário de and drs.is_primary_replica = 1 no final do script. Na camada de serviço Comercialmente Crítico, esse filtro garante que apenas os detalhes da réplica primária sejam lidos.

-- 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, também é possível usar o comando Get-AzSqlInstanceLink do PowerShell ou o comando az sql mi link show da CLI do Azure para buscar a propriedade LastHardenedLsn do link na Instância Gerenciada de SQL e obter as mesmas informações que a consulta T-SQL anterior.

Importante

Verifique novamente se sua carga de trabalho foi interrompida no primário. Verifique se os LSNs no SQL Server e na Instância Gerenciada de SQL correspondem e permanecem correspondentes e inalterados por algum tempo. Os LSNs estáveis em ambas as instâncias indicam que o log final foi replicado para a secundária e a carga de trabalho foi efetivamente interrompida.

Fazer failover de um banco de dados

Se você deseja usar o PowerShell para fazer failover de um banco de dados entre o SQL Server 2022 e a Instância Gerenciada de SQL mantendo o link, ou para fazer failover com perda de dados em 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 específico para o seu ambiente. É possível fazer 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 ao fazer failover ou migrar seu banco de dados, independentemente da versão do SQL Server, use o comando Remove-AzSqlInstanceLink do PowerShell ou o comando az sql mi link delete da CLI do Azure.

Cuidado

  • Antes de fazer failover, pare a carga de trabalho no banco de dados de origem para permitir que o banco de dados replicado seja completamente atualizado e passe por failover sem perda de dados. Se você realizar um failover forçado ou quebrar o link antes que os LSNs correspondam, pode haver perda de dados.
  • O failover de um banco de dados no SQL Server 2019 e em versões anteriores quebra e remove o link entre as duas réplicas. Não é possível realizar o failback para a primária inicial.
  • O failover de um banco de dados ao manter o vínculo com o SQL Server 2022 está, atualmente, em versão prévia.

O script de exemplo a seguir quebra o link e encerra a replicação entre as réplicas, tornando o banco de dados de leitura/gravação em ambas as instâncias. Substitua:

  • <ManagedInstanceName> pelo nome da instância gerenciada.
  • <DAGName> com o nome do link que você está passando por failover (saída da propriedade Name do comando Get-AzSqlInstanceLink 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, o link é descartado e não existe mais. O banco de dados de SQL Server e o banco de dados de Instância Gerenciada de SQL podem executar uma carga de trabalho de leitura/gravação. Eles são completamente independentes. Redirecione a cadeia de conexão do aplicativo para o banco de dados que deseja usar ativamente.

Importante

Após o failover bem-sucedido para a Instância Gerenciada de SQL, reencaminhe manualmente a cadeia de conexão da aplicação para o FQDN da Instância Gerenciada de SQL para concluir o processo de migração ou falha e continuar executando no Azure.

Limpar os grupos de disponibilidade

Como o failover com o SQL Server 2022 não quebra o link, você pode optar por deixar o link e os grupos de disponibilidade no lugar.

Se você decidir quebrar o link ou se estiver fazendo failover com o SQL Server 2019 e versões anteriores, é necessário excluir o grupo de disponibilidade distribuído para remover os metadados do link do SQL Server. No entanto, você pode optar por manter o grupo de disponibilidade no SQL Server.

Para limpar os recursos do grupo de disponibilidade, substitua os seguintes valores e execute o código de exemplo: No código a seguir, substitua:

  • <DAGName> com o nome do grupo de disponibilidade distribuído no SQL Server (usado para criar o link).
  • <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 <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Solucionar problemas

Esta seção fornece orientações para lidar com problemas na configuração e uso do link.

Erros

Caso encontre uma mensagem de erro ao criar o link ou fazer failover de um banco de dados, revise a mensagem de erro na janela de saída da consulta para obter mais informações.

Caso encontre um erro ao trabalhar com o link, a consulta para de ser executada na etapa em que falhou. Após a resolução da condição de erro, execute novamente o comando para prosseguir com a ação.

Estado inconsistente após failover forçado

O uso de failover forçado pode resultar em um estado inconsistente entre as réplicas primária e secundária, causando um cenário de split brain em que ambas as réplicas estão na mesma função. A replicação de dados falhará nesse estado até que o usuário resolva a situação designando manualmente uma réplica como primária e a outra como secundária.

Conteúdo relacionado

Para obter mais informações sobre o recurso de link, consulte estes artigos: