Partilhar via

Replicação transacional com a Instância Gerenciada SQL do Azure

Aplica-se a:Azure SQL Managed Instance

A replicação transacional é um recurso da Instância Gerenciada do SQL do Azure e do SQL Server que permite replicar dados de uma tabela na Instância Gerenciada do SQL do Azure ou de uma instância do SQL Server para tabelas colocadas em bancos de dados remotos. Esse recurso permite sincronizar várias tabelas em diferentes bancos de dados.

Overview

Você pode usar a replicação transacional para enviar por push as alterações feitas em uma instância gerenciada do SQL do Azure para:

  • Um banco de dados do SQL Server (local ou em uma máquina virtual do Azure)
  • Uma base de dados na Base de Dados SQL do Azure
  • Um banco de dados na Instância Gerenciada SQL do Azure

Note

Para usar todos os recursos da Instância Gerenciada SQL do Azure, você deve usar as versões mais recentes do SQL Server Management Studio (SSMS) e do SSDT (SQL Server Data Tools).

Components

Os principais componentes na replicação transacional são o Editor, o Distribuidor e o Assinante, conforme mostrado na imagem a seguir:

Diagrama de replicação com o Azure SQL.

Role Base de Dados SQL do Azure Azure SQL Managed Instance
Publisher No Yes
Distributor No Yes
Puxar assinante No Yes
Assinante Push Yes Yes

A Editora publica as alterações feitas em algumas tabelas (artigos) enviando as atualizações para o Distribuidor. O publicador pode ser uma instância gerida do Azure SQL ou uma instância do SQL Server.

O Distribuidor recolhe as alterações nos artigos de um Editor e distribui-as aos Subscritores. O Distribuidor pode ser uma instância gerenciada do SQL do Azure ou uma instância do SQL Server (qualquer versão, desde que seja igual ou superior à versão do Publisher).

O Subscritor recebe as alterações efetuadas no Publicador. Uma instância do SQL Server e uma instância gerida do SQL do Azure podem ter assinaturas push e pull, embora uma assinatura pull não seja suportada quando o distribuidor é uma instância gerida do SQL do Azure e o assinante não o é. Um banco de dados no Banco de Dados SQL do Azure só pode ser um assinante por push.

A Instância Gerenciada SQL do Azure pode dar suporte a ser um Assinante das seguintes versões do SQL Server:

Note

Para outras versões do SQL Server que não oferecem suporte à publicação em objetos no Azure, você pode usar o método de republicação de dados para mover dados para versões mais recentes do SQL Server.

Tentar configurar a replicação usando uma versão mais antiga pode resultar em erro MSSQL_REPL20084 (O processo não pôde se conectar ao assinante) e MSSQL_REPL40532 (Não é possível abrir o nome< do servidor >solicitado pelo login. O login falhou).

Tipos de replicação

Existem diferentes tipos de replicação:

Replication Base de Dados SQL do Azure Azure SQL Managed Instance
Transacional padrão Sim (apenas como assinante) Yes
Snapshot Sim (apenas como assinante) Yes
Replicação de mesclagem No No
Peer-to-peer No No
Bidirectional No Yes
Subscrições atualizáveis No No

Matriz de capacidade de suporte

A matriz de suporte à replicação transacional e de instantâneo para a Instância Gerenciada SQL do Azure é a mesma do SQL Server:

Publisher Distributor Subscriber
Instância Gerenciada SQL do AzureAUTD Instância Gerenciada SQL do AzureAUTD Banco de Dados SQL do Azure
Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2025
Instância Gerenciada SQL do Azure2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Instância Gerenciada SQL do Azure2025 Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2025		 Banco de Dados SQL do Azure
Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2025
Instância Gerenciada SQL do Azure2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Instância Gerenciada SQL do Azure2022 Azure SQL Managed InstanceAUTDAzure SQL Managed Instance2025
Instância Gerenciada SQL do Azure2022		 Banco de Dados SQL do Azure
Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2022 (16.x) SQL Server 2025 (17.x)
SQL Server 2022 (16.x)		 Banco de Dados SQL do Azure
Base de dados SQL no Microsoft Fabric1
Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2025
Instância Gerenciada SQL do Azure2022
SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2019 (15.x) SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)		 Base de Dados SQL do Azure
Instância Gerenciada SQL do AzureAUTD
Instância Gerenciada SQL do Azure2025
Instância Gerenciada SQL do Azure2022
SQL Server 2025 (17.x)
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2017 (14.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)		 Instância Gerenciada SQL do Azure2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2016 (13.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)		 SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2014 (12.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)		 SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)		 SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)

AUTD Aplica-se à Instância Gerida do Azure SQL configurada com a política de atualização Sempre Atualizada.
2025 Aplica-se à Instância Gerenciada SQL do Azure configurada com a política de atualização do SQL Server 2025.
2022 Aplica-se à Instância Gerenciada SQL do Azure configurada com a política de atualização do SQL Server 2022 .
1 Aplica-se com base nos requisitos das configurações suportadas para o banco de dados SQL no Microsoft Fabric.

Quando utilizar

A replicação transacional é útil nos seguintes cenários:

  • Publique as alterações feitas em uma ou mais tabelas em um banco de dados e distribua-as para um ou vários bancos de dados em uma instância do SQL Server ou Banco de Dados SQL do Azure que se inscreveu para as alterações.
  • Mantenha vários bancos de dados distribuídos em estado sincronizado.
  • Migre bancos de dados de uma instância do SQL Server ou da Instância Gerenciada SQL do Azure para outro banco de dados publicando continuamente as alterações.

Compare a sincronização de dados com a replicação transacional

Category Sincronização de Dados Replicação transacional
Advantages - Suporte ativo ativo
- Bidirecional entre o local e o Banco de Dados SQL do Azure		 - Menor latência
- Consistência transacional
- Reutilizar topologia existente após a migração
Disadvantages - Sem consistência transacional
- Maior impacto no desempenho		 - Não é possível publicar a partir da Base de Dados SQL do Azure
- Alto custo de manutenção

Configurações comuns

Em geral, o editor e o distribuidor devem estar na nuvem ou no local. As configurações a seguir são suportadas:

Publicador com distribuidor local na instância gerenciada SQL

Instância única como Publicador e Distribuidor.

O publicador e o distribuidor são configurados em uma única instância gerenciada pelo SQL e distribuem as alterações para outra instância gerenciada do SQL, Banco de Dados SQL ou instância do SQL Server.

Publicador com distribuidor remoto numa Instância Gerida de SQL Server

Nessa configuração, uma instância gerenciada SQL publica alterações em um distribuidor colocado em outra instância gerenciada SQL que pode servir muitas instâncias gerenciadas SQL de origem e distribuir alterações para um ou vários destinos no Banco de Dados SQL do Azure, na Instância Gerenciada SQL do Azure ou no SQL Server.

Instâncias separadas para Publisher e Distributor.

O editor e o distribuidor são configurados em duas instâncias gerenciadas. Existem algumas restrições com esta configuração:

  • Ambas as instâncias gerenciadas estão na mesma vNet.
  • Ambas as instâncias gerenciadas estão no mesmo local.

Editor/distribuidor local com assinante remoto

Base de Dados SQL do Azure como assinante.

Nessa configuração, um banco de dados no Banco de Dados SQL do Azure ou na Instância Gerenciada SQL do Azure é um assinante. Essa configuração dá suporte à migração do local para o Azure. Se um assinante for um banco de dados no Banco de Dados SQL do Azure, ele deverá estar no modo de push.

Requirements

  • Use a Autenticação SQL para conectividade entre participantes da replicação.
  • Utilize uma partilha na Conta de Armazenamento do Azure para o diretório de trabalho usado pela replicação.
  • Abra a porta de saída TCP 445 nas regras de segurança da sub-rede para acessar o compartilhamento de arquivos do Azure.
  • Abra a porta de saída TCP 1433 quando a instância gerida pelo SQL for o Editor/Distribuidor e o Subscrevente não. Também pode ser necessário alterar a regra de segurança de saída NSG da instância gerenciada SQL para allow_linkedserver_outbound a tag do Serviço de Destino da porta 1433 de virtualnetwork para internet.
  • Coloque o editor e o distribuidor na nuvem ou ambos no local.
  • Configure o emparelhamento VPN entre as redes virtuais dos participantes da replicação se as redes virtuais forem diferentes.

Note

Você pode encontrar o erro 53 ao se conectar a um Arquivo de Armazenamento do Azure se a porta 445 do NSG (grupo de segurança de rede) de saída estiver bloqueada quando o distribuidor for um banco de dados da Instância Gerenciada SQL do Azure e o assinante estiver local. Atualize o vNet NSG para resolver esse problema.

Segurança

Suporte a TLS 1.3

A Instância Gerenciada SQL do Azure dá suporte ao TLS 1.3 para conexões de replicação inicializadas por agentes configurados para serem executados em uma instância gerenciada pelo SQL. Isso se aplica a uma topologia de replicação entre duas instâncias gerenciadas pelo SQL e também a qualquer versão do SQL Server como assinante de um editor e distribuidor de instância gerenciada do SQL.

Se você usar o TLS 1.3 para proteger as conexões entre instâncias em uma topologia de replicação, especifique um valor de 3 ou 4 para o parâmetro -EncryptionLevel de cada agente de replicação:

Um valor de 3 impõe conexões TLS 1.3 a instâncias gerenciadas SQL, mas não tem impacto nas conexões com SQL Servers. Um valor de 4 impõe conexões TLS 1.3 entre as instâncias geridas do SQL, bem como as conexões da instância gerida do SQL para o SQL Server, e requer que instale o certificado no host do SQL Server.

Iniciar sessão replAgentUser

Para fins de replicação transacional, uma instância gerida pelo SQL tem um login(s) pré-criado(s) com o nome replAgentUser. Esse logon é membro da sysadmin função de servidor e é usado por agentes de replicação que precisam se conectar a uma instância gerenciada SQL que participa da configuração de replicação transacional.

Se a replicação transacional não for usada, o login replAgentUser poderá ser desativado. Ele pode ser reativado posteriormente se você decidir começar a usar a replicação transacional.

Limitations

A replicação transacional tem algumas limitações específicas da Instância Gerenciada SQL do Azure. Saiba mais sobre essas limitações nesta seção.

Os arquivos de instantâneo não são excluídos da Conta de Armazenamento do Azure

A Instância Gerenciada SQL do Azure está usando a Conta de Armazenamento do Azure configurada pelo usuário para arquivos instantâneos usados para replicação transacional. Ao contrário do SQL Server no ambiente local, a Instância Gerenciada SQL do Azure não está excluindo arquivos de instantâneo da Conta de Armazenamento do Azure. Assim que os ficheiros deixarem de ser necessários, deve eliminá-los. Isso pode ser feito por meio da interface de Armazenamento do Azure no portal do Azure, do Gerenciador de Armazenamento do Microsoft Azure ou por meio de clientes de linha de comando (Azure PowerShell ou CLI) ou da API REST de Gerenciamento de Armazenamento do Azure.

Aqui está um exemplo de como você pode excluir um arquivo e como você pode excluir uma pasta vazia.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Número de agentes de distribuição em funcionamento contínuo

O número de agentes de distribuição configurados para execução contínua é limitado a 30 na Instância Gerenciada SQL do Azure. Para ter mais agentes de distribuição, eles precisam estar funcionando sob demanda ou com um cronograma definido. A programação pode ser definida com frequência diária e ocorrência a cada 10 segundos (ou mais), portanto, mesmo que não seja contínua, você ainda pode ter um distribuidor que está introduzindo latência de apenas alguns segundos. Quando é necessário um grande número de distribuidores, recomenda-se o uso de configuração programada e não contínua.

Com grupos de redundância

Há suporte para o uso da replicação transacional com instâncias que estão num grupo de failover. No entanto, se você configurar a replicação antes de adicionar sua instância gerenciada SQL a um grupo de failover, a replicação será pausada quando você começar a criar seu grupo de failover e o monitor de replicação mostrará um status de Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. A replicação é recomeçada uma vez que o grupo de failover é criado com êxito.

Se uma instância gerida do SQL do editor ou do distribuidor estiver num grupo de failover, o administrador da instância gerida do SQL deverá remover todas as publicações no antigo primário e reconfigurá-las no novo primário após um failover ter ocorrido. As seguintes atividades são necessárias neste cenário:

  1. Pare todos os trabalhos de replicação em execução no banco de dados, se houver.

  2. Remova os metadados de assinatura do publicador executando o seguinte script na base de dados do publicador. Substitua os valores <name of publication> e <name of subscriber>

    EXEC sp_dropsubscription @publication = '<name of publication>',
    @article = 'all',
    @subscriber = '<name of subscriber>'

  3. Remova os metadados da assinatura do assinante. Execute o seguinte script na base de dados de subscrição na instância SQL gerida do assinante. Substitua o valor <full DNS of publisher>. Por exemplo: example.ac2d23028af5.database.windows.net

    EXEC sp_subscription_cleanup
   @publisher = N'<full DNS of publisher>',
   @publisher_db = N'<publisher database>',
   @publication = N'<name of publication>';

  4. Elimine à força todos os objetos de replicação do publicador executando o seguinte script no banco de dados de publicação:

    EXEC sp_removedbreplication;

  5. Remova de forma forçada o distribuidor antigo da instância SQL gerida primária original (se estiver a fazer failover para um primário antigo que tinha um distribuidor). Execute o seguinte script no master banco de dados na instância gerenciada SQL do distribuidor antigo:

    EXEC sp_dropdistributor 1, 1;

Se uma instância gerida de SQL de um assinante estiver num grupo de failover, a publicação deve ser configurada para se conectar ao endpoint de escuta do grupo de failover para a instância gerida de SQL do assinante. No caso de um failover, a ação subsequente do administrador da instância gerenciada SQL depende do tipo de failover que ocorreu:

  • Para um failover sem perda de dados, a replicação continuará funcionando após o failover.
  • Para um failover com perda de dados, a replicação também funciona. Ele replica as mudanças perdidas novamente.
  • Para um failover com perda de dados, mas se a perda de dados estiver fora do período de retenção da base de dados de distribuição, o administrador da instância gerida SQL precisa reinicializar a base de dados de subscrição.

Resolver problemas comuns

Log de transações e replicação transacional

Em circunstâncias normais, o log de transações é usado para registrar alterações dos dados em um banco de dados. As alterações são registradas no log de transações, e isso faz com que o consumo de armazenamento de log cresça. Há também um processo automático que permite o truncamento seguro do log de transações, e esse processo reduz o espaço de armazenamento usado para o log. Quando a publicação para Replicação Transacional é configurada, impede-se o truncamento do log de transações até que as alterações no log sejam processadas pelo job de leitura do log. Em algumas circunstâncias, o processamento do log de transações é efetivamente bloqueado, e esse estado pode levar ao preenchimento de todo o armazenamento reservado para o log de transações. Quando não há espaço livre para o log de transações e não há mais espaço para o seu crescimento, temos um log de transações cheio. Nesse estado, o banco de dados não pode mais processar nenhuma carga de trabalho de gravação e efetivamente se torna banco de dados somente leitura.

Agente leitor de log desativado

Às vezes, a publicação da Replicação Transacional é configurada para um banco de dados, mas o agente de leitura de registos não está configurado para funcionar. Nesse caso, as alterações estão se acumulando no log de transações e não estão sendo processadas. Isso leva ao crescimento constante do log transacional e, eventualmente, ao log de transações completo. O utilizador deve certificar-se de que a tarefa de leitura de logs existe e está ativa. A alternativa seria desativar a Replicação Transacional, se não for necessária.

Tempos limite de consulta do agente leitor de log

Às vezes, o trabalho do leitor de log não pode progredir efetivamente devido a tempos limite de consulta repetidos. Uma forma de corrigir os tempos limite de consulta é aumentar a configuração do tempo limite para o trabalho do agente leitor de logs.

Aumentar o tempo limite de consulta para a tarefa de leitura de logs pode ser feito com o SSMS. No pesquisador de objetos, em SQL Server Agent, localize o trabalho que você deseja modificar. Primeiro, pare-o e, em seguida, abra suas propriedades. Encontre-o step 2 e edite-o. Anexe o valor do comando com -QueryTimeout <timeout_in_seconds>. Para o valor de tempo limite da consulta, tente 21600 ou superior. Finalmente, comece o trabalho novamente.

O tamanho do armazenamento de log atingiu o limite máximo de 2 TB

Quando o tamanho do armazenamento do log de transações atinge o limite máximo, que é de 2 TB, o log fisicamente não pode crescer mais do que isso. Nesse caso, a única atenuação disponível é marcar como processadas todas as transações que devem ser replicadas, para permitir que o log das transações seja truncado. Isso significa efetivamente que as transações restantes no log não serão replicadas e você precisará reinicializar a replicação.

Note

Depois de executar a mitigação, você precisará reinicializar a replicação, o que significa replicar todo o conjunto de dados novamente. Esse é o tamanho da operação de dados e pode ser de longa execução, dependendo da quantidade de dados que devem ser replicados.

Para executar a mitigação, primeiro você precisa parar o agente do leitor de logs no distribuidor. Em seguida, deve executar o sp_repldone procedimento armazenado com o sinalizador reset definido como 1 na base de dados do publicador, para permitir o truncamento do log de transações. Este comando deve ter esta EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1aparência. Depois disso, você precisará reinicializar a replicação.

Próximos passos

Para obter mais informações sobre como configurar a replicação transacional, consulte os seguintes tutoriais:

Conteúdo relacionado

  • Last updated on