Configurar link com scripts - Instância Gerenciada SQL do Azure

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

Este artigo ensina como configurar um link entre o SQL Server e o Azure SQL Managed Instance com Transact-SQL e scripts do PowerShell ou do Azure CLI. 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, o primário inicial pode ser o SQL Server ou a Instância Gerenciada SQL do Azure. Para o SQL Server 2019 e versões anteriores, o primário inicial deve ser o 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 no local para replicação contínua de dados em um ambiente híbrido entre a réplica primária e secundária, ou pode fazer failover do banco de dados para a réplica secundária, migrar para o Azure ou para recuperação de desastres. Para o SQL Server 2019 e versões anteriores, o failover para a Instância Gerida do SQL do Azure interrompe a ligação e o failback não é suportado. Com o SQL Server 2022, você tem a opção de manter o link e fazer failback 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 neste artigo para configurar manualmente o link entre o SQL Server e a Instância Gerenciada SQL do Azure. 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 assinatura ativa do Azure. Se não tiver uma, crie uma conta gratuita.
• Versão com suporte do SQL Server com a atualização de serviço necessária instalada.
• Instância Gerenciada SQL do Azure. Começa se não o tiveres.
• O módulo do PowerShell Az.SQL 6.0.0 ou superiorou Azure CLI 2.67.0 ou superior. Ou, de preferência, use Azure Cloud Shell online a partir do navegador da Web para executar os comandos, porque ele está sempre atualizado com as versões mais recentes do módulo.
• 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 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 do SQL.
• O erro 1475 no primário inicial do SQL Server 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 da Instância Gerida do SQL para o SQL Server 2022, a instância gerida deve ser configurada com a política de atualização do SQL Server 2022 . A replicação de dados e o failover da Instância Gerenciada do SQL para o SQL Server 2022 não são suportados por instâncias configuradas com a política de atualização sempreup-todata.
• Embora você possa estabelecer um link do SQL Server 2022 para uma instância gerenciada do SQL configurada com a política de atualização sempreup-todata, após o failover para a Instância Gerenciada do SQL, você não poderá mais replicar dados ou fazer failover para o SQL Server 2022.

Permissões

Para o SQL Server, deve ter permissões de sysadmin .

Para a Instância Gerida SQL do Azure, deve ser membro de Colaborador de Instância Gerida SQLou ter as seguintes permissões de funções personalizadas:

Terminologia e convenções de nomenclatura

Ao executar scripts deste guia do usuário, é importante não confundir os nomes do SQL Server e da Instância Gerenciada do 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:

¹ A configuração da Instância Gerenciada SQL do Azure como sua principal inicial é suportada a partir de SQL Server 2022 CU10.

Configurar recuperação e backup de banco de dados

Se o SQL Server for seu 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 a Instância Gerida SQL do Azure faz backups automaticamente, ignore esta etapa se a Instância Gerida SQL for a sua instância principal inicial.

Execute o código a seguir no SQL Server para todos os bancos de dados que você deseja 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, a segurança e a confiança precisam ser configuradas entre as duas instâncias por meio do ponto de extremidade de espelhamento do banco de dados do grupo de disponibilidade.

A confiança baseada em certificados é a única forma suportada para proteger os endpoints de espelhamento de bases de dados para SQL Server e Instância Gerida SQL. Se você tiver grupos de disponibilidade existentes que usam a 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. Você pode fazer isso usando a instrução ALTER ENDPOINT, conforme mostrado mais adiante neste artigo.

A lista a seguir lista uma visão geral do processo para proteger pontos de extremidade de espelhamento de banco de dados para SQL Server e SQL Managed Instance:

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

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

Criar um certificado no SQL Server e importar sua chave pública para a Instância Gerenciada do 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 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

Em seguida, gere 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

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 valores de SQLServerCertName e SQLServerPublicKey da saída, porque você precisará dela para a 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 do Azure em sua conta.

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

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 do SQL Server em formato binário, que você registrou na etapa anterior. É um valor de cadeia de caracteres longa que começa com 0x.
• <SQLServerCertName> com o nome do certificado do SQL Server que você registrou 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 dessa operação é um resumo do certificado do SQL Server carregado no Azure.

Se precisar ver todos os certificados do SQL Server carregados numa instância gerida, use o PowerShell Get-AzSqlInstanceServerTrustCertificate ou o comando da CLI do Azure az sql mi partner-cert list no Azure Cloud Shell. Para remover o certificado do SQL Server carregado numa instância gerida do SQL, use o comando Remove-AzSqlInstanceServerTrustCertificate do PowerShell ou 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 SQL do Azure. Obtenha a chave pública do certificado da Instância Gerenciada do SQL e importe-a para o SQL Server usando o Get-AzSqlInstanceEndpointCertificate PowerShell ou az sql mi endpoint-cert show comando da CLI do Azure, como o exemplo do PowerShell a seguir.

Execute o seguinte script. Substituir:

• <SubscriptionID> com a tua ID de subscrição do 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 PublicKey (começa com 0x) como você exigirá 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.

Em seguida, importe a chave pública obtida do certificado de segurança da instância gerenciada para o SQL Server. Execute a seguinte instrução no SQL Server para criar o certificado de ponto de extremidade MI. Substituir:

• <ManagedInstanceFQDN> com o nome de domínio totalmente qualificado da instância gerenciada.
• <PublicKey> com o valor da PublicKey obtido na etapa anterior (a partir do 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 confiáveis do Azure para o SQL Server

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

Primeiro, importe o certificado de autoridade raiz 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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --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 exists.'
GO

Em seguida, importe o certificado de autoridade raiz PKI 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 = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --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 exists.'
GO

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

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

Validar o certificado

Depois de criar os certificados, valide se o certificado de ponto de extremidade MI está configurado corretamente.

Primeiro, determine a certificate_id do certificado MI exportado substituindo o valor de <ManagedInstanceFQDN> e, em seguida, executando a seguinte consulta no SQL Server:

-- Run on SQL Server 
USE MASTER 
GO 

SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

Em seguida, valide o certificado substituindo o valor de <certificate_id> do resultado da consulta anterior e, em seguida, executando a seguinte consulta no SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Uma resposta de Commands completed successfully. Completion time: … indica que o certificado de ponto de extremidade MI foi validado com êxito.

Se encontrar um erro, elimine o certificado e siga os passos na seção Obter a chave pública do certificado da Instância Gerida do SQL e importá-la para o SQL Server para reimportar o certificado.

Para descartar o certificado, execute a seguinte consulta no SQL Server:

-- Run on SQL Server 

USE MASTER 
GO 

DROP CERTIFICATE [<ManagedInstanceFQDN>] 
GO 

Proteger o endpoint de espelhamento de bases 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 do SQL Server gerado anteriormente. 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.

Criar e proteger o ponto de extremidade de espelhamento de banco 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 ponto de extremidade 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 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 do 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

Para validar que o endpoint de espelhamento foi criado, execute 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 habilitada.

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 satisfaz as seguintes condições obrigatórias para o link:

• 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 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 de ponto de extremidade connection_auth_desc existente não está CERTIFICATEou encryption_algorthm_desc não está AES, o ponto de extremidade precisará ser alterado para atender aos requisitos.

No caso do SQL Server, o mesmo ponto de extremidade de espelhamento de base de dados é utilizado tanto para grupos de disponibilidade como para grupos de disponibilidade distribuídos. Se o ponto de extremidade connection_auth_desc for NTLM (autenticação do Windows) ou KERBEROS, e precisares da autenticação do Windows para um grupo de disponibilidade existente, é possível alterar o ponto de extremidade para utilizar múltiplos métodos de autenticação, alternando 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 usa 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 os endpoints de mirroring, consulte a página de documentação para sys.database_mirroring_endpoints.

O script a seguir é 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 do SQL Server gerado (obtido em uma das etapas anteriores acima).

Dependendo da 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 de ponto de extremidade ALTER e definir o modo de autenticação dupla como 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 o seu endpoint de espelhamento da base de dados para uma ligação de Instância Gerida 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 no SQL Server, independentemente de qual será o primário inicial.

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

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 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ída para cada link de banco de dados entre o SQL Server e a Instância Gerenciada do 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 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 é movido para connected somente quando é associado à 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 Pesquisador de Objetos do SSMS para localizar 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 Azure CLI para criar o link, como o exemplo do PowerShell nesta seção. A criação do link a partir de uma instância gerenciada SQL primária não é suportada atualmente com a CLI do Azure.

Se precisar ver todos os links numa instância gerida, utilize o comando Get-AzSqlInstanceLink do PowerShell ou az sql mi link show da 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 conexão entre a Instância Gerenciada do SQL 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 atualizando o DMV até que a conexão apareça como CONNECTED para a réplica da Instância Gerenciada 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, do Pesquisador de Objetos no SSMS poderá mostrar inicialmente o banco de dados replicado na réplica secundária em um estado Restaurando à medida que a fase inicial de propagação se move e restaura o backup completo do banco 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 propagaçã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 sua instância primária inicial, é importante fazer o primeiro backup de do log de transações no SQL Server após a conclusão da propagação inicial, quando o banco de dados não estiver mais no estado Restaurando... na Instância Gerenciada SQL do Azure. Em seguida, faça backups de log de transações do SQL Server regularmente para minimizar o crescimento excessivo do log enquanto o SQL Server estiver na função principal.

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

Solte 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 

Em seguida, execute o seguinte script T-SQL no SQL Server para descartar 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 de Instância Gerida
• Configurar vínculo entre o SQL Server e a instância gerenciada do SQL com o 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 do link de Instância Gerenciada
• Recuperação de desastres com instância gerenciada link

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

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