Configurar ligação com scripts - Azure SQL Managed Instance

Aplica-se a: Azure SQL Managed Instance

Este artigo ensina-te a configurar um link entre SQL Server e Azure SQL Managed Instance com Transact-SQL e scripts PowerShell ou CLI do Azure. Com o link, as bases de dados do seu primário original são replicadas para a sua réplica secundária quase em tempo real.

Depois que o link for criado, você poderá fazer failover para sua réplica secundária para fins de migração ou recuperação de desastres.

Visão geral

Use o recurso de link para replicar bancos de dados da réplica primária inicial para a réplica secundária. Para o SQL Server 2022, a instância primária inicial pode ser SQL Server ou Azure SQL Managed Instance. Para o SQL Server 2019 e versões anteriores, a instância principal 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.

Pode optar por deixar a ligação para replicação contínua de dados num ambiente híbrido entre a réplica primária e secundária, ou pode fazer o failover da base de dados para a réplica secundária, para migrar para o Azure, ou para recuperação após desastres. Para o SQL Server 2019 e versões anteriores, fazer failover para o Azure SQL Managed Instance quebra a ligação e o fail back não é suportado. Com o SQL Server 2022, tem a opção de manter a conexão e alternar entre as duas réplicas.

Se você planeja usar sua instância gerenciada secundária apenas para recuperação de desastres, poderá economizar nos custos de licenciamento ativando o benefício de failover híbrido .

Use as instruções deste artigo para configurar manualmente a ligação entre o SQL Server e o Azure SQL Managed Instance. Depois que o link é criado, o banco de dados de origem obtém 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 subscrição ativa do Azure. Se não tiver uma, crie uma conta gratuita.
• Versão suportada de SQL Server com a atualização de serviço necessária instalada.
• Azure SQL Managed Instance. Começa se não o tiveres.
• Módulo PowerShell Az.SQL 6.0.0 ou superior, ou CLI do Azure 2.67.0 ou superior. Ou, de preferência, usar Azure Cloud Shell online a partir do navegador web para executar os comandos, porque está sempre atualizado com as versões mais recentes dos módulos.
• Um ambiente devidamente preparado.

Considere o seguinte:

• O recurso de link suporta um banco de dados por link. Para replicar vários bancos de dados em uma instância, crie um link para cada banco de dados individual. Por exemplo, para replicar 10 bases de dados para SQL Managed Instance, crie 10 ligações individuais.
• O ordenamento entre o SQL Server e o SQL Managed Instance deve ser o mesmo. Uma incompatibilidade na colação pode causar uma inconsistência na capitalização do nome do servidor e impedir uma ligação bem-sucedida do SQL Server para o SQL Managed Instance.
• O erro 1475 no seu SQL Server primário inicial indica que precisa de iniciar uma nova cadeia de backups criando um backup completo sem a opção COPY ONLY.
• Para estabelecer uma ligação, ou failover, de SQL Managed Instance para o SQL Server 2025, a sua SQL Managed Instance deve estar configurada com a política de atualização SQL Server 2025. A replicação de dados e o failover de SQL Managed Instance para SQL Server 2025 não são suportados por instâncias configuradas com uma política de atualização incompatível.
• Para estabelecer uma ligação, ou failover, de uma instância gerida de SQL para SQL Server 2022, a sua instância gerida de SQL deve estar configurada com a política de atualização SQL Server 2022. A replicação de dados e o failover de SQL Managed Instance para SQL Server 2022 não são suportados por instâncias configuradas com uma política de atualização incompatível.
• Embora possa estabelecer uma ligação de uma versão suportada 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 a SQL Managed Instance, já não poderá replicar dados nem retornar à sua instância de SQL Server.

Permissões

Para SQL Server, deves ter permissões sysadmin.

Para Azure SQL Managed Instance, deve ser membro do SQL Managed Instance Contributor, ou ter as seguintes permissões de função personalizadas:

Terminologia e convenções de nomenclatura

Ao executar scripts deste guia de utilizador, é importante não confundir os nomes do SQL Server e do SQL Managed Instance com os seus domínios totalmente qualificados (FQDNs). A tabela a seguir explica o que os vários nomes representam exatamente e como obter seus valores:

¹ Configurar Azure SQL Managed Instance como primário inicial é suportado a partir de SQL Server 2022 CU10.

Configurar recuperação e backup de banco de dados

Se o SQL Server for o seu primário inicial, então as bases de dados que serão replicadas através do link devem estar no modelo de recuperação completo e ter pelo menos uma cópia de segurança. Como o Azure SQL Managed Instance aceita backups automaticamente, ignora este passo se o SQL Managed Instance for o teu principal inicial.

Quando crias uma ligação, a seed inicial entre as réplicas primária e secundária acontece fazendo uma cópia de segurança completa da base de dados na réplica primária, transferindo-a para a réplica secundária e restaurando-a lá. Quando fizer o backup completo, recomendamos que use a WITH CHECKSUM opção para garantir que o backup é válido e não tem qualquer corrupção. Para mais informações, consulte BACKUP (Transact-SQL).

Execute o seguinte código no SQL Server para todas as bases de dados que pretende replicar. Substitua <DatabaseName> pelo nome real 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 obter mais informações, consulte Criar um backup completo de banco de dados.

Estabeleça confiança entre instâncias

Primeiro, você deve estabelecer confiança entre as duas instâncias e proteger os pontos de extremidade usados para se comunicar e criptografar dados na rede. Os grupos de disponibilidade distribuída utilizam o ponto de extremidade do espelhamento de base de dadosdo grupo de disponibilidade existente , em vez de terem o seu próprio ponto de extremidade dedicado. Como tal, é necessário configurar a segurança e a confiança entre as duas instâncias através do endpoint de espelhamento do banco de dados do grupo de disponibilidade.

A confiança baseada em certificados é a única forma suportada de proteger endpoints de espelhamento de bases de dados para SQL Server e SQL Managed Instance. Se tiver grupos de disponibilidade existentes que utilizam autenticação Windows, precisa de adicionar confiança baseada em certificado ao ponto final de espelhamento existente como opção secundária de autenticação. Você pode fazer isso usando a instrução ALTER ENDPOINT, conforme mostrado mais adiante neste artigo.

Segue-se uma visão geral do processo para proteger endpoints de espelhamento de bases de dados tanto para SQL Server como para SQL Managed Instance:

1. Gerar um certificado no SQL Server e obter a sua chave pública.
2. Obtenha uma chave pública do certificado SQL Managed Instance.
3. Exchange as chaves públicas entre o SQL Server e o SQL Managed Instance.
4. Importar chaves de autoridade de certificação raiz confiáveis no Azure para o SQL Server

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

Crie um certificado no SQL Server e importe a sua chave pública para a SQL Managed Instance

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 mantenha-a em um local 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

Depois, gera um certificado de autenticação no SQL Server. No seguinte script substitua:

• @cert_expiry_date com a data de expiração do certificado desejada (data futura).

Registre essa data e defina um lembrete para girar (atualizar) o certificado do SQL Server antes de sua data de 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

Depois, utilize 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, 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 valores de SQLServerCertName e SQLServerPublicKey da saída, porque você precisará dela para a próxima etapa ao importar o certificado.

Primeiro, certifique-se de que iniciou sessão no Azure e que selecionou a subscrição onde a sua instância gerida está alojada. Selecionar a subscrição correta é especialmente importante se tiver mais do que uma subscrição do Azure na sua conta.

Substitua <SubscriptionID> pelo seu ID de subscrição 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

Depois, 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 o seguinte exemplo do PowerShell.

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

• <SQLServerPublicKey> com a parte pública do certificado de SQL Server em formato binário, que registou no passo anterior. É um valor de cadeia de caracteres longa que começa com 0x.
• <SQLServerCertName> com o nome do certificado de SQL Server que registou na etapa anterior.
• <ManagedInstanceName> com o nome abreviado da 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 desta operação é um resumo do certificado SQL Server carregado para o Azure.

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

Obtenha a chave pública do certificado do SQL Managed Instance e importe-a para o SQL Server

O certificado para proteger o endpoint de ligação é gerado automaticamente no Azure SQL Managed Instance. Obtenha a chave pública do certificado da SQL Managed Instance e importe-a para SQL Server usando o comando Get-AzSqlInstanceEndpointCertificate PowerShell ou az sql mi endpoint-cert show CLI do Azure, como o seguinte exemplo PowerShell.

Execute o seguinte script. Substituir:

• <SubscriptionID> com o seu ID de subscrição Azure.
• <ManagedInstanceName> com o nome abreviado da 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 irá necessitá-la na próxima etapa.

Como alternativa, se encontrar problemas ao copiar e colar a chave pública, também poderá executar o comando T-SQL EXEC sp_get_endpoint_certificate 4 na instância sob gestão para obter a sua chave pública para a extremidade do link.

De seguida, importa a chave pública obtida do certificado de segurança da instância gerida para o SQL Server. Execute a seguinte consulta no SQL Server para criar o certificado de endpoint MI. Substituir:

• <ManagedInstanceFQDN> com o nome de domínio totalmente qualificado da instância gerenciada.
• <PublicKey> com o valor da Chave Pública obtido na etapa anterior (a partir de Azure Cloud Shell, começando por 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 confiáveis no Azure para o SQL Server

Importar chaves de autoridade certificadora raiz (CA) confiáveis no Azure para o SQL Server é necessário para que o seu SQL Server confie nos certificados de chave pública da SQL Managed Instance emitidos pelo Azure.

Pode descarregar as chaves necessárias da autoridade de certificação raiz em detalhes da Autoridade Certificadora Azure. No mínimo, descarregue os certificados DigiCert Global Root G2 e Microsoft RSA Root Certificate Authority 2017 e importe-os para a sua instância SQL Server. No entanto, se planeia manter o link por mais do que alguns meses, então descarregue e importe todos os 7 certificados listados na secção Root Certificate Authorities para evitar potenciais interrupções caso Azure atualize a sua lista de CA de confiança.

Guarde os certificados localmente na instância SQL Server, como no caminho de amostra C:\Path\To\<name of certificate>.crt, e depois importe os certificados desse caminho usando o script Transact-SQL seguinte. Substitua <name of certificate> pelo nome real do certificado, 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 exibição de gerenciamento dinâmico (DMV):

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

Validar a cadeia de certificados

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

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

Proteger o endpoint de espelhamento de bases de dados

Se não tiver um grupo de disponibilidade existente, ou um endpoint de espelhamento de base de dados no SQL Server, o passo seguinte é criar um endpoint de espelhamento de base de dados no SQL Server e protegê-lo com o certificado SQL Server previamente gerado. Se você tiver um grupo de disponibilidade ou ponto de extremidade de espelhamento existente, pule para a seção Alterar um ponto de extremidade existente.

Crie e proteja o endpoint de espelhamento da base de dados no SQL Server

Para verificar se não existe um ponto final de espelhamento de base de dados já 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 endpoint de espelhamento de base de dados existente, execute o seguinte script no SQL Server para obter o nome do certificado 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 da saída, pois você precisará dela na próxima etapa.

Use o script seguinte para criar um novo endpoint de espelhamento de base de dados na porta <EndpointPort> e garantir o endpoint com o certificado SQL Server. Substituir:

• <SQL_SERVER_CERTIFICATE> com o nome de 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 que o endpoint 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 de endpoint criada com êxito deveria indicar STARTED.

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

Alterar um ponto de extremidade existente

Se estiver a usar grupos de disponibilidade existentes para a ligação, ou se houver um ponto de extremidade de espelhamento de base de dados existente, valide primeiro se cumpre as seguintes condições obrigatórias para a ligação:

• O tipo deve ser DATABASE_MIRRORING.
• A autenticação de conexão deve ser CERTIFICATE.
• A encriptação tem de estar ativada.
• O algoritmo de encriptação deve ser AES.

Execute a seguinte consulta no SQL Server para visualizar detalhes de um endpoint de espelhamento de base 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 ponto de extremidade DATABASE_MIRRORING existente não está connection_auth_desc ou CERTIFICATE não está encryption_algorithm_desc, o ponto de extremidade AES.

No SQL Server, o mesmo endpoint de espelhamento de base de dados é usado tanto para grupos de disponibilidade como para grupos de disponibilidade distribuídos. Se o seu endpoint connection_auth_desc for NTLM (autenticação Windows) ou KERBEROS, e precisar de autenticação Windows para um grupo de disponibilidade existente, pode alterar o endpoint para utilizar múltiplos métodos de autenticação mudando a opção de autenticação para NEGOTIATE CERTIFICATE. Esta alteração permite que o grupo de disponibilidade existente utilize a autenticação do Windows, ao mesmo tempo que utiliza a autenticação por certificado para o SQL Managed Instance.

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 os endpoints de mirroring, consulte a página de documentação para sys.database_mirroring_endpoints.

O script seguinte é um exemplo de como alterar o seu endpoint de espelhamento de base de dados existente no SQL Server. Substituir:

• <YourExistingEndpointName> com o nome do ponto de extremidade existente.
• <SQLServerCertName> com o nome do certificado de SQL Server gerado (obtido numa das etapas anteriores acima).

Dependendo da sua configuração específica, talvez seja necessário personalizar ainda mais o script. 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 ALTER endpoint e definir o modo de autenticação dual para Windows e certificate, use esta consulta novamente no SQL Server para mostrar detalhes do endpoint de espelhamento da base 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

Modificou com sucesso o seu endpoint de espelhamento de base de dados para um link SQL Managed Instance.

Crie um grupo de disponibilidade no SQL Server

Se não tiver um grupo de disponibilidade existente, o passo seguinte é criar um no SQL Server, independentemente de qual será o principal inicial.

Os comandos para criar o grupo de disponibilidade são diferentes se a sua Instância Gerida do SQL for a primária inicial, o que só é suportado a partir de SQL Server 2022 CU10.

Embora seja possível estabelecer vários links para o mesmo banco de dados, o link suporta apenas a replicação de um banco de dados por link. Se quiseres criar múltiplos links para a mesma base de dados, usa o mesmo grupo de disponibilidade para todos os links, mas depois cria um novo grupo de disponibilidade distribuído para cada link de base de dados entre o SQL Server e o SQL Managed Instance.

-- 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 seguinte 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 connectede o estado dos seus grupos de disponibilidade distribuídos precisa ser disconnected. O estado do grupo de disponibilidade distribuída só passa para connected depois de estar ligado à SQL Managed Instance.

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

Em alternativa, pode usar o SSMS Object Explorer para encontrar grupos de disponibilidade e grupos de disponibilidade distribuídos. Expanda a pasta Always On High Availability e, em seguida, a pasta Availability Groups.

Criar um link

Finalmente, você pode criar o link. Os comandos diferem com base em qual instância é a primária inicial. Use o comando New-AzSqlInstanceLink PowerShell ou az sql mi link create CLI do Azure para criar o link, como no exemplo do PowerShell nesta secção. Criar a ligação a partir de uma "SQL Managed Instance" principal não é atualmente suportada com a CLI do Azure.

Se precisares de ver todas as ligações numa instância gerida, usa 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 desta operação é um carimbo de data/hora da solicitação de execução bem-sucedida do criar um link.

Verifique o link

Para verificar a ligação entre o SQL Managed Instance e o SQL Server, execute a seguinte consulta no SQL Server. A conexão não será instantânea. Pode levar até um minuto para que o Detran comece a mostrar uma conexão bem-sucedida. Continue a atualizar o DMV até a ligação aparecer como CONNECTED para a réplica do SQL Managed Instance.

-- 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 de estabelecida a ligação, Object Explorer no SSMS pode inicialmente mostrar a base de dados replicada na réplica secundária num estado Restauração à medida que a fase inicial de seed avança e restaura o backup completo da base de dados. Depois de o banco de dados ser restaurado, a replicação precisa recuperar a sincronização para colocar os dois bancos de dados em sincronia. O banco de dados não estará mais no Restaurando após o término da inicialização inicial. A inicialização de bases de dados pequenas pode ser rápida o suficiente para que o utilizador não veja o estado inicial Restaurando no SSMS.

Faça o primeiro backup do log de transações

Se o SQL Server for o seu primário inicial, é importante fazer o primeiro backup do log de transações no SQL Server depois da inicialização ser concluída, quando a base de dados já não estiver no estado de Restauração... na Instância Gerida do Azure SQL. Depois, faça regularmente backups dos registos de transações do SQL Server para minimizar o crescimento excessivo dos logs quando o SQL Server está na função principal.

Se o SQL Managed Instance for o seu principal, não precisa de tomar qualquer ação, pois o Azure SQL Managed Instance faz backups de logs automaticamente.

Coloque um link

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

Primeiro, use o comando Remove-AzSqlInstanceLink PowerShell para soltar o link, como o exemplo a seguir:

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

Depois, execute o seguinte script T-SQL no SQL Server para eliminar o grupo de disponibilidade distribuída. Substitua <DAGName> pelo nome do grupo de disponibilidade distribuída usado para criar o link:

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

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

DROP AVAILABILITY GROUP <AGName>  
GO 

Solução de problemas

Se você encontrar 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, consulte para solucionar problemas com o link.

Conteúdo relacionado

Para usar o link:

• Preparar o ambiente para o link do Managed Instance
• Configurar a ligação entre SQL Server e a Instância Gerida do SQL com SSMS
• Failover da ligação
• 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 de link da Instância Gerida
• Recuperação de desastres com Managed Instance link

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

• Replicação transacional com SQL Managed Instance
• Serviço de Reprodução de Log (LRS)