Partilhar via

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

  • Artigo

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

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. Esta funcionalidade permite sincronizar várias tabelas em diferentes bases de dados.

Descrição geral

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
  • Uma base de dados de instância no Azure SQL Managed Instance

Nota

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

Componentes

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

Diagram of replication with Azure SQL.

Função Base de Dados SQL do Azure Instância Gerida do Azure SQL
Fabricante No Yes
Distribuidor No Yes
Puxar assinante No Yes
Subscritor Push Yes Sim

A Editora publica as alterações feitas em algumas tabelas (artigos) enviando as atualizações para o Distribuidor. O editor pode ser uma instância gerenciada do SQL do Azure 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 Editor. Uma instância do SQL Server e uma instância gerenciada do SQL do Azure podem ser assinantes push e pull, embora uma assinatura pull não seja suportada quando o distribuidor é uma instância gerenciada do SQL do Azure e o assinante nã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:

Nota

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:

Replicação Base de Dados SQL do Azure Instância Gerida do Azure SQL
Transacional padrão Sim (apenas como assinante) Yes
Instantâneo Sim (apenas como assinante) Yes
Replicação de intercalação No No
Ponto a ponto No No
Bidirecional No Yes
Subscrições atualizáveis No Não

Matriz de capacidade de suporte

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

Fabricante Distribuidor Subscritor
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Quando utilizar o

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

Categoria Sincronização de Dados Replicação transacional
Vantagens - 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
Desvantagens - 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

Single instance as Publisher and Distributor.

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 na Instância Gerenciada SQL

Nessa configuração, uma instância gerenciada SQL publica alterações em um distribuidor colocadas 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.

Separate instances for Publisher and 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

Azure SQL Database as subscriber.

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.

Requisitos

  • Use a Autenticação SQL para conectividade entre participantes da replicação.
  • Use um compartilhamento da 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 gerenciada pelo SQL for o Editor/Distribuidor e o Assinante 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.

Nota

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.

Limitações

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 failover

Há suporte para o uso da replicação transacional com instâncias que estão em um 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 é retomada assim que o grupo de failover é criado com êxito.

Se uma instância gerenciada SQL do editor ou distribuidor estiver em um grupo de failover, o administrador da instância gerenciada do SQL deverá limpar todas as publicações no primário antigo e reconfigurá-las no novo primário após a ocorrência de um failover. 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. Solte os metadados de assinatura do publisher executando o seguinte script no banco de dados do publisher. Substitua os <name of publication> valores e <name of subscriber> :

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

  3. Solte os metadados da assinatura do assinante. Execute o script a seguir no banco de dados de assinatura na instância gerenciada SQL do assinante. Substitua o <full DNS of publisher> valor. 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. Solte com força todos os objetos de replicação do publisher executando o seguinte script no banco de dados publicado:

    EXEC sp_removedbreplication;

  5. Solte com força o distribuidor antigo da instância gerenciada SQL primária original (se fizer failover para um primário antigo que costumava ter 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 gerenciada do SQL do assinante estiver em um grupo de failover, a publicação deverá ser configurada para se conectar ao ponto de extremidade do ouvinte do grupo de failover para a instância gerenciada do 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 a perda de dados estiver fora do período de retenção do banco de dados de distribuição, o administrador da instância gerenciada SQL precisa reinicializar o banco de dados de assinatura.

Resolver problemas comuns

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

Em circunstâncias normais, o log de transcação é usado para registrar as 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, o truncamento do log de transações é impedido até que as alterações no log sejam processadas pelo trabalho de leitura de 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 log de transações crescer, temos o log de transações completo. 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 do leitor de logs não está configurado para ser executado. 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 transcação completo. O usuário deve certificar-se de que o trabalho de leitor de log existe e está ativo. 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 maneira de corrigir os tempos limite de consulta é aumentar a configuração de tempo limite de consulta para o trabalho do agente do leitor de logs.

O aumento do tempo limite de consulta para o trabalho de leitor de log 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 todas as transações que devem ser replicadas como processadas, para permitir que o log de 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.

Nota

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, você deve executar o procedimento armazenado com reset o sp_repldone sinalizador definido como 1 no banco de dados do editor, 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:

Consulte também