Configurar a vinculação com scripts – Instância Gerenciada de SQL do Azure

Applies to:Instância Gerenciada de SQL do Azure

Este artigo ensina como configurar um link entre SQL Server e 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.

Visão geral

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

Você pode optar por deixar o link em vigor para replicação de dados contínua em um ambiente híbrido entre a réplica primária e secundária ou fazer failover do banco de dados para a réplica secundária, para migrar para Azure ou para recuperação de desastre. Para o SQL Server 2019 e versões anteriores, o failover para o Instância Gerenciada de SQL do Azure quebra o link, e o failback não é suportado. Com SQL Server 2022, você tem a opção de manter o link e fazer failback entre as duas réplicas.

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.

Use as instruções neste artigo para configurar manualmente o link entre SQL Server e 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.

Pré-requisitos

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

• Uma assinatura de Azure ativa. Se você não tiver uma, crie uma conta gratuita.
• Versão compatível do SQL Server com a atualização de serviço necessária instalada.
• Instância Gerenciada de SQL do Azure. Caso não tenha, comece agora.
• Módulo do PowerShell Az.SQL 6.0.0 ou superior ou CLI do Azure 2.67.0 ou superior. Ou, preferencialmente, use Azure Cloud Shell online do navegador da Web para executar os comandos, pois ele é sempre atualizado com as versões mais recentes do módulo.
• Um ambiente adequadamente preparado.

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 Instância Gerenciada de SQL, crie 10 links individuais.
• A collation entre SQL Server e Instância Gerenciada de SQL deve ser a mesma. Uma incompatibilidade na ordenação pode causar uma incompatibilidade na diferenciação de maiúsculas e minúsculas dos nomes de servidor e impedir uma conexão bem-sucedida do SQL Server para a Instância Gerenciada de SQL.
• O erro 1475 no SQL Server primário inicial indica que você precisa iniciar uma nova cadeia de backup criando um backup completo sem a opção COPY ONLY.
• Para estabelecer um link, ou failover, de Instância Gerenciada de SQL para o SQL Server 2025, sua Instância Gerenciada de SQL deve ser configurada com a política de atualização SQL Server 2025. A replicação de dados e o failover de Instância Gerenciada de SQL para SQL Server 2025 não têm suporte em instâncias configuradas com uma política de atualização incompatível.
• Para estabelecer um link ou failover de Instância Gerenciada de SQL para SQL Server 2022, sua Instância Gerenciada de SQL deve ser configurada com a política de atualização SQL Server 2022. A replicação de dados e o failover de Instância Gerenciada de SQL para SQL Server 2022 não são suportados por instâncias configuradas com uma política de atualização incompatível.
• Embora você possa estabelecer um link de uma versão compatível do SQL Server para uma SQL managed instance configurada com a política de atualização Always-up-to-date, após o failover para Instância Gerenciada de SQL, você não poderá mais replicar dados ou fazer failback para sua instância de SQL Server.

Permissões

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

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

Terminologia e convenções de nomenclatura

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

¹ Configurar o Instância Gerenciada de SQL do Azure como seu primário inicial é suportada a partir de SQL Server 2022 CU10.

Configurar recuperação e backup de banco de dados

Se SQL Server for o primário inicial, os bancos de dados que serão replicados por meio do link deverão estar no modelo de recuperação completa e ter pelo menos um backup. Como o Instância Gerenciada de SQL do Azure faz backups automaticamente, pule esta etapa se o Instância Gerenciada de SQL for seu primário inicial.

Quando você cria um link, a propagação inicial entre as réplicas primária e secundária acontece fazendo um backup completo do banco de dados na réplica primária, transferindo-o para a réplica secundária e restaurando-o lá. Ao fazer o backup completo, recomendamos que você use a opção WITH CHECKSUM para garantir que o backup seja válido e não tenha nenhuma corrupção. Para obter mais informações, consulte BACKUP (Transact-SQL).

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.

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 integridade precisam ser configuradas entre as duas instâncias por meio do endpoint de espelhamento do banco de dados do grupo de disponibilidade.

A confiança baseada em certificado é a única maneira suportada de proteger pontos de extremidade de espelhamento de banco de dados para SQL Server e Instância Gerenciada de SQL. Se você tiver grupos de disponibilidade existentes que usam autenticação do Windows, precisará adicionar 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.

A seguir, é apresentada uma visão geral do processo para proteger os endpoints de espelhamento de banco de dados para SQL Server e Instância Gerenciada de SQL:

1. Gere um certificado em SQL Server e obtenha sua chave pública.
2. Obtenha uma chave pública do certificado Instância Gerenciada de SQL.
3. Trocar as chaves públicas entre o SQL Server e o Instância Gerenciada de SQL.
4. Importar chaves de autoridade de certificação raiz Azure confiáveis para SQL Server

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

Criar um certificado no SQL Server e importar sua chave pública para Instância Gerenciada de SQL

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 seguinte script, substitua:

• @cert_expiry_date com a 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.

-- 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 sua instância gerenciada está hospedada. Selecionar a assinatura adequada é especialmente importante se você tiver mais de uma assinatura Azure em sua conta.

Substitua <SubscriptionID> pela ID da assinatura 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 PowerShell ou az sql mi partner-cert create CLI do Azure para carregar a chave pública do certificado de autenticação de SQL Server para Azure, como a seguinte amostra do PowerShell.

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

• <SQLServerPublicKey> com a parte pública do certificado SQL Server no formato binário, que você registrou na etapa anterior. É um valor de cadeia longo que começa com 0x.
• <SQLServerCertName> com o nome do certificado 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 de SQL Server carregado para Azure.

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

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

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

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 SQL Server. Execute a seguinte consulta no SQL Server para criar o certificado de ponto de extremidade MI. Substitua:

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

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

Importar chaves de autoridade de certificação raiz Azure confiáveis para SQL Server

A importação de chaves de autoridade de certificação raiz (AC) Azure confiáveis para SQL Server é necessária para que seu SQL Server confie nos certificados de chave pública Instância Gerenciada de SQL emitidos pelo Azure.

Você pode baixar as chaves raiz de CA necessárias de detalhes da Autoridade de Certificação do Azure. No mínimo, baixe os certificados DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017 e importe-os para sua instância de SQL Server. No entanto, se você planeja executar o link por mais de alguns meses, baixe e importe todos os 7 certificados listados na seção Root Certificate Authorities para evitar possíveis interrupções caso Azure atualize sua lista de autoridades de certificação confiáveis.

Salve os certificados locais na instância de SQL Server, como o caminho C:\Path\To\<name of certificate>.crt de exemplo e importe os certificados desse caminho usando o script Transact-SQL a seguir. Substitua <name of certificate> pelo nome do certificado real, como DigiCert Global Root G2 ou Microsoft RSA Root Certificate Authority 2017.

-- Run on SQL Server
-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'<name of certificate>')
BEGIN
    PRINT 'Creating <name of certificate> certificate.'
    CREATE CERTIFICATE [<name of certificate>] FROM FILE = 'C:\Path\To\<name of certificate>.crt'

    --Trust certificates issued by <name of certificate> root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('<name of certificate>')
    --For government cloud, use the corresponding SQL Database DNS suffix, e.g. '*.database.usgovcloudapi.net', '*.database.chinacloudapi.cn' etc.
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate <name of certificate> already exists.'
GO

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

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

Validar a cadeia de certificados

Alterações agendadas ou não intencionais em certificados podem prejudicar o link. Para evitar interrupções, é importante validar periodicamente a cadeia de certificados em SQL Server.

Ignore esta etapa se você estiver configurando um novo link ou tiver importado recentemente os certificados, conforme descrito nas seções anteriores.

Proteger o endereço de espelhamento do banco de dados

Se você não tiver um grupo de disponibilidade existente ou 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 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 de 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 novo ponto de extremidade de espelhamento de banco de dados na porta <EndpointPort> e proteger o ponto de extremidade com o certificado SQL Server. Substitua:

• <SQL_SERVER_CERTIFICATE> com o nome 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=<EndpointPort>, 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 endpoint criado com sucesso deve indicar STARTED.

Um novo endpoint de espelhamento foi criado com a autenticação por certificado e a criptografia AES ativada.

Alterar um ponto de extremidade 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 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_algorithm_descnão éAES, o ponto de extremidade precisará ser alterado para atender aos requisitos.

No SQL Server, o mesmo endpoint de espelhamento de banco de dados é usado para Grupos de Disponibilidade e Grupos de Disponibilidade Distribuídos. Se o ponto de extremidade connection_auth_desc for NTLM (autenticação do Windows) ou KERBEROS e você precisar de autenticação do Windows para um grupo de disponibilidade existente, é possível alterar o ponto de extremidade para usar vários métodos de autenticação alterando a opção de autenticação para NEGOTIATE CERTIFICATE. Essa alteração permite que o grupo de disponibilidade existente use a autenticação do Windows, enquanto utiliza a autenticação de certificado para a Instância Gerenciada do 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 do sys.database_mirroring_endpoints.

O script a seguir é um exemplo de como modificar um endpoint de espelhamento de banco de dados existente no SQL Server. Substitua:

• <YourExistingEndpointName> pelo nome do ponto de extremidade existente.
• <SQLServerCertName> com o nome do certificado de 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=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Depois de executar a consulta do endpoint ALTER e definir o modo de autenticação dupla como Windows e certificado, use essa consulta novamente no SQL Server para mostrar os detalhes do endpoint de espelhamento do 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 o endpoint de espelhamento de banco de dados para um link de conexão de Instância Gerenciada do SQL.

Criar um grupo de disponibilidade no SQL Server

Se você não tiver um grupo de disponibilidade existente, a próxima etapa será criar um em SQL Server, independentemente do qual será o primário inicial.

Os comandos para criar o grupo de disponibilidade serão diferentes se o Instância Gerenciada de SQL for o primário inicial, que só terá suporte a partir de SQL Server CU10 2022.

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 você quiser 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 SQL Server e Instância Gerenciada de SQL.

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

-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
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>:<EndpointPort>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

-- 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'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

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

-- Run on SQL Server 
-- Create the availability group on SQL Server 

CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>] 
WITH (CLUSTER_TYPE = NONE) 
FOR  
REPLICA ON N'<SQLServerName>' 
WITH ( 
    ENDPOINT_URL = N'TCP://<SQLServerIP>:<EndpointPort>', 
    FAILOVER_MODE = MANUAL, 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
    SEEDING_MODE = AUTOMATIC); 

GO 

-- Run on SQL Server 
-- Grant permission to the availability group to create databases 

ALTER AVAILABILITY GROUP [<AGNameOnSQLServer>] GRANT CREATE ANY DATABASE; 

-- 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'<AGNameOnSQLServer>' WITH  
    ( 
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC, 
      SESSION_TIMEOUT = 20 
    ), 
    N'<AGNameOnSQLMI>' WITH 
    ( 
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>];Database=[<DatabaseName>]', 
      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 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 passa para connected somente depois de ingressar no Instância Gerenciada de 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.

Criar um link

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 PowerShell ou az sql mi link create CLI do Azure para criar o link, como o exemplo do PowerShell nesta seção. No momento, não há suporte para a criação do link de um Instância Gerenciada de SQL primário com o CLI do Azure.

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

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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 + ":<EndpointPort>"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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>" 

# Enter the Azure subscription ID 
$SubscriptionID = "<SubscriptionID>" 
 
# ==== Do not customize the following cmdlet ==== 

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

# Build properly formatted connection endpoint 
$DestinationIP = "TCP://" + $SQLServerIP + ":<EndpointPort>"  

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $DestinationIP -InstanceLinkRole Primary

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

Verifique o link

Para verificar a conexão entre Instância Gerenciada de SQL e 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 o DMV até que a conexão apareça como CONECTADO 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 for estabelecida, Pesquisador de Objetos no SSMS poderá mostrar inicialmente o banco de dados replicado na réplica secundária em um estado Restoring à 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 deixará de estar em Restauração após a conclusão da propagação inicial. 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.

Fazer o primeiro backup de log de transações

Se SQL Server for o primário inicial, é importante fazer o primeiro backup do log de transações no SQL Server após a conclusão da semeadura inicial, quando o banco de dados não estiver mais no estado Restoring... no Instância Gerenciada de SQL do Azure. Em seguida, faça regularmente backups de log de transações do SQL Server para minimizar o crescimento excessivo de logs enquanto o SQL Server estiver no papel principal.

Se Instância Gerenciada de SQL for o principal, você não precisará executar nenhuma ação, pois Instância Gerenciada de SQL do Azure faz backups de log automaticamente.

Descartar um link

Se você quiser descartar o link, seja porque ele não é mais necessário ou porque está em um estado irreparável e precisa ser recriado, poderá fazer isso com o PowerShell e T-SQL.

Primeiro, use o comando Remove-AzSqlInstanceLink do PowerShell para descartar o link, como no seguinte exemplo:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force 

Em seguida, execute o script T-SQL a seguir no SQL Server para remover o grupo de disponibilidade distribuído. Substitua <DAGName> pelo nome do grupo de disponibilidade distribuído usado para criar o link.

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

Por fim, opcionalmente, você poderá remover o grupo de disponibilidade se não tiver mais uso para ele. Para fazer isso, substitua o <AGName> pelo nome do grupo de disponibilidade e execute-o na respectiva instância:

DROP AVAILABILITY GROUP <AGName>  
GO 

Solucionar problemas

Caso encontre uma mensagem de erro ao criar o link, revise a mensagem de erro na janela de saída da consulta para obter mais informações. Para obter mais informações, analise solucionar problemas com o link.

Conteúdo relacionado

Para usar o link:

• Preparar o ambiente para o link da Instância Gerenciada
• Configurar link entre SQL Server e Instância Gerenciada do SQL com SSMS
• Alternar para o link de backup
• Migrar com o Link
• Práticas recomendadas para manter o link
• Solucionar problemas com o link

Para saber mais sobre o link:

• Visão geral do link de Instância Gerenciada
• Recuperação de desastres com link de Instância Gerenciada

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

• Replicação transacional com Instância Gerenciada de SQL
• LRS (Serviço de Reprodução de Log)