Partilhar via

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

  • Artigo

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

Este artigo ensina como configurar um link entre o SQL Server e a Instância Gerenciada SQL do Azure com scripts Transact-SQL e PowerShell ou CLI do Azure. Com o link, os bancos de dados do primário inicial são replicados para a 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.

Nota

Descriçã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, os bancos de dados do primário inicial são replicados 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 Gerenciada SQL do Azure quebra o link 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 - esse recurso está atualmente em visualização.

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.

Gorjeta

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

Pré-requisitos

Nota

Algumas funcionalidades do link estão geralmente disponíveis, enquanto algumas estão atualmente em visualização. Revise a capacidade de suporte da versão para saber mais.

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

Considere o seguinte:

  • O recurso de link suporta um banco de dados por link. Para replicar 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 COPY ONLY opção.

Permissões

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

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

Recurso Microsoft.Sql/ Permissões necessárias
Microsoft.Sql/managedInstances /ler, /escrever
Microsoft.Sql/managedInstances/hybridCertificate /ação
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /ler
Microsoft.Sql/managedInstances/hybridLink /ler, /escrever, /excluir
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

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:

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

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

Configurar recuperação e backup de banco de dados

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

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.

Nota

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

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ídos usam o ponto de extremidade de espelhamento de banco de dados de grupo de disponibilidade existente, em vez de ter 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.

Nota

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

A confiança baseada em certificado é a única maneira com suporte para proteger pontos de extremidade de espelhamento de banco de dados para SQL Server e Instância Gerenciada 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 ALTER ENDPOINT instrução, conforme mostrado mais adiante neste artigo.

Importante

Os certificados são gerados com uma data e hora de validade. Devem ser renovados e rodados antes de expirarem.

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 master banco de dados, se ela ainda não estiver presente. Insira sua senha no lugar do <strong_password> 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 validade 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.

Importante

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

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

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

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

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

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

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

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

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

Salve 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> pelo seu ID da subscrição 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 você precisar ver todos os certificados do SQL Server carregados em uma instância gerenciada, use o comando Get-AzSqlInstanceServerTrustCertificate PowerShell ou az sql mi partner-cert list Azure CLI no Azure Cloud Shell. Para remover o certificado do SQL Server carregado em uma instância gerenciada do SQL, use o comando Remove-AzSqlInstanceServerTrustCertificate PowerShell ou az sql mi partner-cert delete Azure CLI 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 comando Get-AzSqlInstanceEndpointCertificate PowerShell ou az sql mi endpoint-cert show Azure CLI, como o exemplo do PowerShell a seguir.

Atenção

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

Execute o seguinte script. Substituir:

  • <SubscriptionID> com a sua 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 você encontrar problemas ao copiar e colar a PublicKey, também poderá executar o comando EXEC sp_get_endpoint_certificate 4 T-SQL na instância gerenciada para obter sua chave pública para o ponto de extremidade do link.

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

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

Importante

O nome do certificado deve ser o FQDN da Instância Gerenciada SQL e não deve ser modificado. O link não estará operacional se estiver usando um nome personalizado.

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

Atenção

Certifique-se de que a PublicKey comece com um 0xarquivo . Talvez seja necessário adicioná-lo manualmente ao início da Chave Pública se ela ainda não estiver lá.

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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

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

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

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

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

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

Proteger o ponto de extremidade 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 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 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 seguinte script no SQL Server para obter o nome do certificado do SQL Server gerado anteriormente.

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

Salve SQLServerCertName 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 5022 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=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

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

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

A coluna de state_desc de ponto de extremidade criada com êxito deve 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

Nota

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

Se você estiver usando grupos de disponibilidade existentes para o link, ou se houver um ponto de extremidade de espelhamento de banco de dados existente, primeiro valide se ele 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 ponto de extremidade existente DATABASE_MIRRORING não é , ou encryption_algorthm_desc não CERTIFICATEAESé, o ponto de extremidade connection_auth_desc precisa ser alterado para atender aos requisitos.

No SQL Server, o mesmo ponto de extremidade de espelhamento de banco de dados é usado para grupos de disponibilidade e grupos de disponibilidade distribuídos. Se o ponto de extremidade for NTLM (autenticação do Windows) ou KERBEROS, e você precisar de autenticação do Windows para um grupo de disponibilidade existente, é possível alterar o connection_auth_desc ponto de extremidade para usar vários 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 possíveis opções para alterar pontos de extremidade, consulte a página de documentação para sys.database_mirroring_endpoints.

O script a seguir é um exemplo de como alterar seu ponto de extremidade de espelhamento de banco de dados existente no SQL Server. 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=5022, 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 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 ALTER dados:

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

Você modificou com êxito seu ponto de extremidade de espelhamento de banco de dados para um link de Instância Gerenciada 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 do 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 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.

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

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

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

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

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

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

Importante

Para o SQL Server 2016, exclua WITH (CLUSTER_TYPE = NONE) da instrução T-SQL acima. Deixe como está para todas as versões posteriores do SQL Server.

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

Substitua os seguintes valores e execute o script T-SQL para criar seu grupo de disponibilidade distribuída.

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

Verificar grupos de disponibilidade

Use o script a seguir para listar todos os grupos de disponibilidade e grupos de disponibilidade distribuídos na instância do SQL Server. Neste ponto, o estado do seu grupo de disponibilidade precisa ser , e o estado dos seus grupos de disponibilidade distribuídos precisa ser connecteddisconnected. O estado do grupo de disponibilidade distribuída é movido para connected somente quando ele é 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.

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 você precisar ver todos os links em uma instância gerenciada, use o comando Get-AzSqlInstanceLink PowerShell ou az sql mi link show Azure CLI no Azure Cloud Shell.

Para simplificar o processo, entre no portal do Azure e execute o seguinte script do Azure Cloud Shell. Substituir:

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

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

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

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

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

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

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

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

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

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

O resultado dessa operação é um carimbo de data/hora da execução bem-sucedida da solicitação criar um 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, o Pesquisador de Objetos no SSMS poderá mostrar inicialmente o banco de dados replicado na réplica secundária em um estado de Restauração à medida que a fase inicial de propagação se move e restaura o backup completo do banco de dados. Depois que o banco de dados é restaurado, a replicação precisa recuperar o atraso para trazer os dois bancos de dados para um estado sincronizado. O banco de dados não estará mais em Restaurando após a conclusão da propagação inicial. A semeadura de bancos de dados pequenos pode ser rápida o suficiente para que você não veja o estado inicial de Restauração no SSMS.

Importante

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

Interromper a carga de trabalho

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

Alternar o modo de replicação

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

A mudança do modo assíncrono para o modo de sincronização requer uma alteração do modo de replicação na Instância Gerenciada do SQL e no SQL Server.

Modo de replicação de switch (instância gerenciada SQL)

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

Primeiro, verifique se você está conectado ao Azure e se selecionou a assinatura em que sua instância gerenciada está hospedada usando o comando Select-AzSubscription PowerShell ou az account set Azure CLI. Selecionar a assinatura adequada é especialmente importante se você tiver mais de uma assinatura do Azure em sua conta.

No exemplo do PowerShell a seguir, substitua <SubscriptionID> pela 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

Certifique-se de saber o nome do link que você gostaria de fazer failover. Você pode usar o comando Get-AzSqlInstanceLink PowerShell ou az sql mi link list Azure CLI.

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

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

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

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

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

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

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

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

No exemplo do PowerShell a seguir, substitua:

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

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

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

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

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

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

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

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

Modo de replicação de switch (SQL Server)

Use o seguinte script T-SQL no SQL Server para alterar o modo de replicação do grupo de disponibilidade distribuída no SQL Server de assíncrono para sincronização. Substituir:

  • <DAGName> com o nome do grupo de disponibilidade distribuída (usado para criar o link).
  • <AGName> com o nome do grupo de disponibilidade criado no SQL Server (usado para criar o link).
  • <ManagedInstanceName> com o nome da instância gerenciada.
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Para confirmar que você alterou o modo de replicação do link com êxito, use a seguinte exibição de gerenciamento dinâmico. Os resultados indicam o SYNCHRONOUS_COMIT estado.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Agora que você alternou a Instância Gerenciada do SQL e o SQL Server para o modo de sincronização, a replicação entre as duas instâncias é síncrona. Se você precisar reverter esse estado, siga as mesmas etapas e defina o estado como async para SQL Server e SQL Managed Instance.

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

Para concluir o failover ou a migração, confirme se a replicação foi concluída. Para isso, verifique se os números de sequência de log (LSNs) nos registros de log do SQL Server e da Instância Gerenciada do SQL são os mesmos.

Inicialmente, espera-se que a LSN no primário seja maior do que a LSN no secundário. A latência da rede pode fazer com que a replicação fique um pouco atrasada em relação à principal. Como a carga de trabalho foi interrompida no primário, você deve esperar que as LSNs correspondam e parem de mudar depois de algum tempo.

Use a seguinte consulta T-SQL no SQL Server para ler o LSN do último log de transações registrado. Substituir:

  • <DatabaseName> com o nome do banco de dados e procure o último número LSN protegido.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Use a seguinte consulta T-SQL na Instância Gerenciada SQL para ler o último LSN protegido para seu banco de dados. Substitua <DatabaseName> pelo nome do banco de dados.

Essa consulta funciona em uma instância gerenciada SQL de uso geral. Para uma Instância Gerenciada SQL Crítica de Negócios, remova o comentário and drs.is_primary_replica = 1 no final do script. Na camada de serviço Crítica para os Negócios, esse filtro garante que os detalhes sejam lidos apenas da réplica principal.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Como alternativa, você também pode usar o comando Get-AzSqlInstanceLink PowerShell ou az sql mi link show Azure CLI para buscar a propriedade do seu link na Instância Gerenciada SQL para fornecer as mesmas informações que a LastHardenedLsn consulta T-SQL anterior.

Importante

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

Failover de um banco de dados

Se você quiser usar o PowerShell para fazer failover de um banco de dados entre o SQL Server 2022 e a Instância Gerenciada do SQL enquanto ainda mantém o link, ou para executar um failover com perda de dados para qualquer versão do SQL Server, use o assistente de Failover entre o SQL Server e a Instância Gerenciada no SSMS para gerar o script para seu ambiente. Você pode executar um failover planejado a partir da réplica primária ou secundária. Para fazer um failover forçado, conecte-se à réplica secundária.

Para quebrar o link e interromper a replicação quando você fizer failover ou migrar seu banco de dados, independentemente da versão do SQL Server, use o comando Remove-AzSqlInstanceLink PowerShell ou az sql mi link delete Azure CLI.

Atenção

  • Antes de fazer failover, interrompa a carga de trabalho no banco de dados de origem para permitir que o banco de dados replicado recupere completamente e faça failover sem perda de dados. Se você executar um failover forçado ou quebrar o link antes da correspondência de LSNs, poderá perder dados.
  • O failover de um banco de dados no SQL Server 2019 e versões anteriores quebra e remove o vínculo entre as duas réplicas. Você não pode voltar para a primária inicial.
  • O failover de um banco de dados enquanto mantém o vínculo com o SQL Server 2022 está atualmente em visualização.

O script de exemplo a seguir quebra o link e encerra a replicação entre suas réplicas, fazendo com que o banco de dados seja lido/gravado em ambas as instâncias. Substituir:

  • <ManagedInstanceName> com o nome da instância gerenciada.
  • <DAGName> com o nome do link que você está fazendo failover (saída da propriedade Name do Get-AzSqlInstanceLink comando executado anteriormente acima).
# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

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

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

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

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Quando o failover é bem-sucedido, o link é descartado e não existe mais. O banco de dados do SQL Server e o banco de dados da Instância Gerenciada do SQL podem executar uma carga de trabalho de leitura/gravação. Eles são completamente independentes. Reaponte a cadeia de conexão do aplicativo para o banco de dados que você deseja usar ativamente.

Importante

Após o failover bem-sucedido para a Instância Gerenciada do SQL, reaponte manualmente a cadeia de conexão do(s) seu(s) aplicativo(s) para o FQDN da instância gerenciada do SQL para concluir o processo de migração ou failover e continuar em execução no Azure.

Limpar grupos de disponibilidade

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

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

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

  • <DAGName> com o nome do grupo de disponibilidade distribuído no SQL Server (usado para criar o link).
  • <AGName> com o nome do grupo de disponibilidade no SQL Server (usado para criar o link).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Resolver problemas

A seção fornece orientação para resolver problemas com a configuração e o uso do link.

Erros

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

Se você encontrar um erro ao trabalhar com o link, a consulta para de ser executada na etapa com falha. Depois que a condição de erro for resolvida, execute novamente o comando para prosseguir com sua ação.

Estado inconsistente após failover forçado

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

Conteúdos relacionados

Para obter mais informações sobre o recurso de link, consulte os seguintes recursos: