Compartilhar via

O que é o Sincronização de Dados SQL para o Azure?

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

Importante

A Sincronização de Dados SQL será desativada em 30 de setembro de 2027. Considere migrar para soluções alternativas de replicação/sincronização de dados.

A Sincronização de Dados SQL é um serviço baseado no Banco de Dados SQL do Azure que permite sincronizar os dados selecionados bidirecionalmente entre vários bancos de dados, no local e na nuvem.

A Sincronização de Dados SQL do Azure não oferece suporte à Instância Gerenciada de SQL do Azure nem ao Azure Synapse Analytics.

Visão geral

A Sincronização de Dados é baseada em torno do conceito de um Grupo de Sincronização. Um Grupo de Sincronização é um grupo de bancos de dados que você deseja sincronizar.

A Sincronização de Dados usa uma topologia hub-spoke para sincronizar os dados. Você define um dos bancos de dados no grupo de sincronização como o banco de dados Hub. O restante dos bancos de dados são bancos de dados de membros. A sincronização ocorre apenas entre o hub e membros individuais.

  • O Banco de Dados Hub deve ser um Banco de Dados SQL do Azure.
  • Os bancos de dados membro podem ser de ambos os bancos de dados do Banco de Dados SQL do Azure ou em instâncias do SQL Server.
  • O Banco de Dados de Metadados de Sincronização contém os metadados e o log para sincronização de dados. O banco de dados de metadados de sincronização deve ser um banco de dados SQL do Azure localizado na mesma região que o banco de dados de Hub. O Banco de Dados de metadados de sincronização é criado pelo cliente e é propriedade do cliente. Você só pode ter um banco de dados de metadados de sincronização por região e assinatura. O banco de dados de metadados de sincronização não pode ser excluído ou renomeado enquanto os grupos de sincronização ou agentes de sincronização existirem. A Microsoft recomenda a criação de um banco de dados vazio para uso como o banco de dados de metadados de sincronização. A Sincronização de Dados cria tabelas nesse banco de dados e executa uma carga de trabalho frequente.

Observação

Se estiver usando um banco de dados local como um banco de dados de membro, você terá que instalar e configurar um agente de sincronização local.

Diagrama que explica o processo de sincronização de dados entre bancos de dados.

Um Grupo de Sincronização tem as seguintes propriedades:

  • O Esquema de Sincronização descreve quais dados estão sendo sincronizados.
  • A Direção da Sincronização pode ser bidirecional ou pode fluir em uma única direção. Ou seja, a Direção da Sincronização pode ser Hub para Membro ou Membro para Hub, ou ambos.
  • O Intervalo de Sincronização descreve a frequência com a qual ocorre a sincronização.
  • A Política de Resolução de Conflito é uma política em nível de grupo, que pode ser Hub ganha ou Membro ganha.

Quando usar

A Sincronização de Dados é útil nos casos em que os dados precisam ser atualizados em vários bancos de dados no Banco de Dados SQL do Azure ou no SQL Server. Estes são os casos de uso principais para Sincronização de Dados:

  • Sincronização de Dados Híbrida: com a Sincronização de Dados, você pode manter os dados sincronizados entre os bancos de dados no SQL Server e no Banco de Dados SQL do Azure para habilitar aplicativos híbridos. Essa funcionalidade pode ser atraente para clientes que estejam avaliando a mudança para a nuvem e gostariam de colocar alguns dos próprios aplicativos no Azure.
  • Aplicativos Distribuídos: em muitos casos, pode ser útil separar diferentes cargas de trabalho em bancos de dados diferentes. Por exemplo, se você tiver um grande banco de dados de produção, mas também precisar executar um relatório ou uma carga de trabalho para análise de dados, é útil ter um segundo banco de dados para essa carga de trabalho adicional. Essa abordagem minimiza o impacto no desempenho da sua carga de trabalho de produção. Você pode usar a Sincronização de Dados para manter esses dois bancos de dados sincronizados.
  • Aplicativos Distribuídos Globalmente: Muitas empresas abrangem várias regiões e até mesmo vários países/regiões. Para minimizar a latência de rede, é melhor ter seus dados em uma região perto de você. Com a sincronização de dados, você pode facilmente manter os bancos de dados em regiões de todo o mundo sincronizados.

A Sincronização de Dados não é a solução preferencial para os cenários a seguir:

Cenário Algumas soluções recomendadas
Recuperação de desastre Backups automatizados no Banco de Dados SQL do Azure
Escala de Leitura Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura
ETL (OLTP para OLAP) Azure Data Factory ou SQL Server Integration Services
Migração do SQL Server para o Banco de Dados SQL do Azure. No entanto, Sincronização de Dados SQL pode ser usado após a conclusão da migração, para garantir que a origem e o destino sejam mantidos em sincronia. Serviço de Migração de Banco de Dados do Azure

Como ele funciona

  • Controle de alterações de dados: A Sincronização de Dados controla alterações usando os gatilhos inserir, atualizar e excluir. As alterações são registradas em uma tabela secundária do banco de dados do usuário. BULK INSERT não dispara gatilhos por padrão. Se FIRE_TRIGGERS não for especificado, nenhum gatilho de inserção será executado. Adicionar a opção de FIRE_TRIGGERS para a Sincronização de dados rastrear essas inserções.
  • Sincronização de dados: a Sincronização de Dados é criada em um modelo Hub-Spoke. O Hub é sincronizado com cada membro individualmente. As alterações do Hub são baixadas para o membro e, em seguida, as alterações do membro são carregadas para o Hub.
  • Resolução de conflitos: A Sincronização de Dados fornece duas opções para a resolução de conflito, Hub ganha ou Membro ganha.
    • Se você selecionar Hub ganha, as alterações no hub sempre substituem as alterações no membro.
    • Se você selecionar Membro ganha, as alterações no membro sempre substituem as alterações no hub. Se houver mais de um membro, o valor final depende de qual membro será sincronizado pela primeira vez.

Comparar com a replicação transacional

Sincronização de Dados Replicação transacional
Vantagens – Suporte ativo-ativo
– Bidirecional entre o Banco de Dados SQL do Azure e o local		 – Menor latência
– Consistência transacional
- Reutilizar a topologia existente após a migração
-Suporte às instâncias gerenciadas do Azure SQL
Desvantagens – Não há consistência transacional
– Maior impacto do desempenho		 - Não é possível publicar do Banco de Dados SQL do Azure
– Alto custo de manutenção

Observação

O link privado da Sincronização de Dados SQL é diferente do Link Privado do Azure.

O novo recurso de link privado permite que você escolha um ponto de extremidade privado gerenciado pelo serviço para estabelecer uma conexão segura entre o serviço de sincronização e seus bancos de dados de membro ou hub durante o processo de sincronização de dados. Um ponto de extremidade privado gerenciado por serviço é um endereço IP privado em uma rede virtual e uma sub-rede específica. Na sincronização de dados, o ponto de extremidade particular gerenciado pelo serviço é criado pela Microsoft e é usado exclusivamente pelo serviço de sincronização de dados para uma determinada operação de sincronização.

Antes de configurar o link privado, leia os requisitos gerais para o recurso.

Diagrama de link privado para sincronização de dados.

Observação

Você deve aprovar manualmente o ponto de extremidade privado gerenciado pelo serviço na página Conexões de ponto de extremidade privado do portal do Azure durante a implantação do grupo de sincronização ou por meio do PowerShell.

Introdução

Configurar a Sincronização de Dados no Portal do Azure

Configurar a Sincronização de Dados com o PowerShell

Configurar a sincronização de dados com a API REST

Revisar as práticas recomendadas para a Sincronização de Dados

Algo deu errado?

Consistência e desempenho

Coerência eventual

Como a Sincronização de Dados é baseada no gatilho, a consistência transacional não é garantida. A Microsoft garante que todas as alterações são feitas, eventualmente, e que a Sincronização de Dados não causa perda de dados.

Impacto sobre o desempenho

A Sincronização de Dados usa os gatilhos inserir, atualizar e excluir para controlar as alterações. Ela cria tabelas secundárias no banco de dados do usuário para controle de alterações. Essas atividades de controle de alterações têm um impacto sobre sua carga de trabalho do banco de dados. Avalie sua camada de serviço e faça a atualização necessário.

Provisionamento e desprovisionamento durante a criação do grupo de sincronização, atualização e exclusão também podem afetar o desempenho do banco de dados.

Requisitos e limitações

Requisitos gerais

  • Cada tabela deve ter uma chave primária. Não altere o valor da chave primária em nenhuma linha. Se você tiver de alterar o valor de uma chave primária, exclua a linha e recrie-a com o novo valor de chave primária.

Importante

Alterar o valor de uma chave primária existente resultará no seguinte comportamento de falha:

  • Os dados entre o Hub e o membro podem ser perdidos, embora a sincronização não relate nenhum problema.
  • A sincronização pode falhar porque a tabela de rastreamento tem uma linha não existente da origem devido à alteração da chave primária.

  • O isolamento de instantâneo deve ser habilitado tanto para membros de sincronização e Hub. Para obter mais informações, consulte Isolamento de instantâneo no SQL Server.

  • Para usar o link privado da Sincronização de Dados, os bancos de dados do membro e do hub devem estar hospedados no Azure (na mesma região ou em regiões diferentes) no mesmo tipo de nuvem (por exemplo, ambos na nuvem pública ou na nuvem governamental). Além disso, os provedores de recursos Microsoft.Network também devem ser registrados para as assinaturas que hospedam os servidores de hub e de membro. Por fim, você deve aprovar manualmente o link privado para a Sincronização de Dados durante a configuração dela na seção "Conexões de ponto de extremidade privado" no portal do Azure ou por meio do PowerShell. Para obter mais informações sobre como aprovar o link privado, consulte Tutorial: configurar a Sincronização de Dados SQL entre bancos de dados no Banco de Dados SQL do Azure e no SQL Server. Depois de aprovar o ponto de extremidade privado gerenciado pelo serviço, toda a comunicação entre o serviço de sincronização e os bancos de dados de membro/hub ocorre sobre o link privado. Os grupos de sincronização existentes podem ser atualizados para que esse recurso seja habilitado.

Limitações gerais

  • Uma tabela não pode ter uma coluna de identidade que não seja a chave primária.
  • Uma chave primária não pode ter os seguintes tipos de dados: sql_variant, binary, varbinary, image, xml.
  • Tenha cuidado ao usar os seguintes tipos de dados como uma chave primária, porque a precisão aceita aplica-se somente ao segundo: time, datetime, datetime2, datetimeoffset.
  • Os nomes de objetos (bancos de dados, tabelas e colunas) não podem conter os caracteres imprimíveis ponto (.), colchete esquerdo ([) ou colchete direito (]).
  • Um nome de tabela não pode conter caracteres imprimíveis ! " # $ % ' ( ) * + - ou espaço.
  • Não há suporte para autenticação com o Microsoft Entra (o antigo Azure Active Directory).
  • Se houver tabelas com o mesmo nome, mas com esquemas diferentes (por exemplo, dbo.customers e sales.customers), somente uma delas poderá ser adicionada à sincronização.
  • Não há suporte para colunas com tipos de dados definidos pelo usuário.
  • Não há suporte para a movimentação de servidores entre assinaturas diferentes.
  • A Sincronização de Dados não dá suporte ao cenário em que duas chaves primárias são diferentes apenas no uso de maiúsculas e minúsculas (por exemplo, Foo e foo).
  • Truncar tabelas não é uma operação com suporte da Sincronização de Dados (as alterações não serão rastreadas).
  • Não há suporte para o uso de um banco de dados de hiperescala do SQL do Azure como um banco de dados de metadados de sincronização ou de hub. No entanto, um banco de dados de Hiperescala pode ser um banco de dados membro em uma topologia de Sincronização de Dados.
  • Não há suporte para tabelas com otimização de memória.
  • As alterações no esquema não são replicadas automaticamente. Uma solução personalizada pode ser criada para automatizar a replicação de alterações de esquema.
  • A Sincronização de Dados dá suporte apenas às duas seguintes propriedades de índice: Unique, Clustered/Non-Clustered. Não há suporte a outras propriedades de um índice como IGNORE_DUP_KEY ou ao predicado do filtro WHERE, e o índice de destino é provisionado sem essas propriedades, mesmo que o índice de origem as tenha definidas.
  • Um banco de dados de trabalhos elásticos não pode ser usado como o banco de dados de metadados de sincronização de dados SQL e vice-versa.
  • A Sincronização de Dados SQL não é compatível com banco de dados do razão.

Tipos de dados sem suporte

  • FileStream
  • SQL/CLR UDT
  • XMLSchemaCollection (suporte para XML)
  • Cursor, RowVersion, Timestamp, Hierarchyid

Não há suporte para os tipos de coluna

A Sincronização de Dados não pode sincronizar colunas somente leitura ou geradas pelo sistema. Por exemplo:

  • Colunas computadas.
  • Colunas geradas pelo sistema para tabelas temporais.

Limitações nas dimensões de serviço e do banco de dados

Dimensões Limite Solução alternativa
Número máximo de grupos de sincronização aos quais qualquer banco de dados pode pertencer. 5
Número máximo de pontos de extremidade em um único grupo de sincronização 30
Número máximo de pontos de extremidade locais em um único grupo de sincronização. 5 Criar vários grupos de sincronização
Nomes de coluna, tabela, esquema e banco de dados 50 caracteres por nome
Tabelas em um grupo de sincronização 500 Criar vários grupos de sincronização
Colunas em uma tabela em um grupo de sincronização 1000
Tamanho da linha de dados em uma tabela 24 Mb

Observação

Poderá haver até 30 pontos de extremidade em um único grupo de sincronização, se houver apenas um grupo de sincronização. Se houver mais de um grupo de sincronização, o número total de pontos de extremidade em todos os grupos de sincronização não pode exceder 30. Se um banco de dados pertencer a vários grupos de sincronização, ele será contado como vários pontos de extremidade, não um.

Requisitos de rede

Observação

Se você usar o link privado de sincronização, esses requisitos de rede não se aplicarão.

Quando o grupo de sincronização é estabelecido, o serviço de sincronização de dados precisa se conectar ao banco de dados hub. No momento em que você estabelece o grupo de sincronização, o SQL Server do Azure deve ter a seguinte configuração nas respectivas definições de Firewalls and virtual networks:

Depois que o grupo de sincronização for criado e provisionado, você poderá desabilitar essas configurações. O agente de sincronização se conecta diretamente ao banco de dados de Hub e você poderá usar as regras de IP de firewall do servidor ou pontos de extremidade privados para permitir que o agente acesse o servidor de hub.

Observação

Se você alterar as configurações de esquema do grupo de sincronização, será necessário permitir que o serviço de sincronização de dados acesse o servidor novamente para que o banco de dados de hub possa ser reprovisionado.

Residência de dados na região

Se você sincronizar dados na mesma região, a Sincronização de Dados SQL não armazenará/processará dados do cliente fora da região em que a instância de serviço é implantada. Se você sincronizar dados entre regiões diferentes, a Sincronização de Dados SQL replicará os dados do cliente para as regiões emparelhadas.

Perguntas Frequentes sobre a Sincronização de Dados SQL

Quanto custa o serviço de Sincronização de Dados SQL?

Não há encargos para o serviço de Sincronização de Dados SQL. No entanto, você ainda acumulará encargos de transferência de dados pela movimentação de dados dentro e fora de sua instância do Banco de Dados SQL. Para obter mais informações, consulte cobranças de transferência de dados.

Quais regiões oferecem suporte à Sincronização de Dados?

A Sincronização de Dados SQL está disponível em todas as regiões.

É necessária uma conta do Banco de Dados SQL?

Sim. Você deve ter uma conta do Banco de Dados SQL para hospedar o banco de dados hub.

Posso usar a Sincronização de Dados para sincronizar somente entre bancos de dados do SQL Server?

Não diretamente. Você pode sincronizar entre bancos de dados do SQL Server indiretamente criando um banco de dados hub no Azure e adicionando os bancos de dados locais ao grupo de sincronização.

Posso configurar a Sincronização de Dados para sincronização entre os bancos de dados do Banco de Dados SQL do Azure que pertencem a assinaturas diferentes?

Sim. Você pode configurar a sincronização entre bancos de dados que pertencem a grupos de recursos de propriedade de assinaturas diferentes, mesmo que as assinaturas pertençam a locatários diferentes.

  • Se as assinaturas pertencerem ao mesmo locatário e você tiver permissão em todas as assinaturas, você poderá configurar o grupo de sincronização no portal do Azure.
  • Caso contrário, será necessário usar o PowerShell para adicionar os membros de sincronização.

É possível configurar a Sincronização de Dados entre bancos de dados no Banco de Dados SQL que pertencem a nuvens diferentes (como a nuvem pública do Azure e Azure operada pela 21Vianet)?

Sim. É possível configurar a sincronização entre bancos de dados que pertencem a nuvens diferentes. Você tem de usar o PowerShell para adicionar os membros de sincronização que pertencem a assinaturas diferentes.

Posso usar a Sincronização de Dados para propagar dados do meu banco de dados de produção para um banco de dados vazio e sincronizá-los?

Sim. Crie o esquema manualmente no novo banco de dados desenvolvendo o script com base no original. Depois de criar o esquema, adicione as tabelas a um grupo de sincronização para copiar os dados e mantê-los sincronizados.

Devo usar a Sincronização de Dados SQL para fazer backup e restaurar meus bancos de dados?

Não é recomendável usar a Sincronização de Dados SQL para criar um backup de seus dados. Você não pode fazer backup e restaurar para um ponto específico no tempo porque as sincronizações da Sincronização de Dados SQL não têm controle de versão. Além disso, a Sincronização de Dados SQL não faz backup de outros objetos SQL, como procedimentos armazenados, e não faz o equivalente a uma operação de restauração rapidamente.

Para ver uma técnica de backup recomendada, consulte Fazer uma cópia transicionalmente consistente de um Banco de Dados SQL do Azure.

A Sincronização de Dados pode sincronizar tabelas e colunas criptografadas?

  • Se um banco de dados usar Always Encrypted, será possível sincronizar apenas as tabelas e colunas não criptografadas. Não é possível sincronizar as colunas criptografadas porque a sincronização de dados não pode descriptografar os dados.
  • Se uma coluna usar a CLE (Criptografia em Nível de Coluna), será possível sincronizar a coluna, desde que o tamanho da linha seja menor que o tamanho máximo de 24 MB. A Sincronização de Dados trata a coluna criptografada pela chave (CLE) como dados binários normais. Para descriptografar os dados em outros membros de sincronização, é necessário ter o mesmo certificado.

Há suporte para ordenações na Sincronização de Dados SQL?

Sim. A Sincronização de Dados SQL oferece suporte à definição de configurações de ordenação nos seguintes cenários:

  • Se as tabelas do esquema de sincronização selecionadas ainda não estiverem em seus bancos de dados hub ou membro, então quando você implantar o grupo de sincronização, o serviço criará automaticamente as tabelas e colunas correspondentes com as configurações de ordenação selecionadas nos bancos de dados de destino vazios.
  • Se as tabelas a serem sincronizadas já existirem nos bancos de dados hub e membro, a Sincronização de Dados SQL exigirá que as colunas de chave primária tenham a mesma ordenação entre bancos de dados hub e membro para implantar com êxito o grupo de sincronização. Não há nenhuma restrição de ordenação em colunas que não sejam colunas de chave primária.

Há suporte para federação na Sincronização de Dados SQL?

O Banco de Dados de Raiz da Federação pode ser usado no Serviço da Sincronização de Dados SQL sem qualquer limitação. Você não pode adicionar o ponto de extremidade do Banco de Dados Federado para a versão atual da Sincronização de Dados SQL.

Posso usar a sincronização de dados para sincronizar dados exportados do Dynamics 365 usando o recurso traga seu próprio banco de dados (BYOD)?

O recurso traga seu próprio banco de dados do Dynamics 365 permite que os administradores exportem entidades de dados do aplicativo para seus próprios bancos de dados SQL do Microsoft Azure. A sincronização de dados pode ser usada para sincronizar esses dados em outros bancos de dado se os dados forem exportados usando o Efetuar push incremental (não há suporte para push completo) e se Habilitar gatilhos no banco de dados de destino estiver definido como Sim.

Como fazer para criar Sincronização de Dados no grupo de Failover a fim de dar suporte à Recuperação de Desastres?

  • Para garantir que as operações de sincronização de dados na região de failover estejam em par com a região primária, após o failover, é necessário recriar manualmente o grupo de sincronização na região de failover com as mesmas configurações da região primária.

Conteúdo relacionado

Atualizar o esquema de um banco de dados sincronizado

Você precisa atualizar o esquema de um banco de dados em um grupo de sincronização? As alterações no esquema não são replicadas automaticamente. Para algumas soluções, consulte os seguintes artigos:

Monitorar e solucionar problemas

A Sincronização de Dados SQL está funcionando conforme o esperado? Para monitorar a atividade e solucionar problemas, consulte os seguintes artigos:

Saiba mais sobre o Banco de Dados SQL do Azure

Para mais informações sobre Banco de Dados SQL do Azure, veja os seguintes artigos: