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

Aplica-se a:Banco de Dados SQL do Azure

Importante

SQL Sincronização de Dados se aposenta em 30 de setembro de 2027. Considere migrar para soluções alternativas de replicação e sincronização de dados. Como parte do processo de aposentadoria, você não pode criar novos grupos de sincronização em assinaturas do Azure que não usavam antes o SQL Sincronização de Dados. Grupos de sincronização existentes podem continuar operando até a data de aposentadoria, mas você deve migrá-los para uma solução alternativa antes dessa data.

SQL Sincronização de Dados é um serviço construído sobre o Banco de Dados SQL do Azure que você pode usar para sincronizar dados selecionados bidirecionalmente em múltiplos bancos de dados, tanto on-premises quanto na nuvem.

SQL do Azure Sincronização de Dados não suporta Instância Gerenciada de SQL do Azure nem 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 de Sincronização pode ser bidirecional, ou pode fluir em apenas uma direção: Hub para Membro, Membro para Hub, ou ambas.
  • 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

  • Acompanhamento de alterações de dados: Sincronização de Dados acompanha as mudanças usando gatilhos de inserção, atualização e deleção. 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 você não especificar FIRE_TRIGGERS, nenhum gatilho de inserção é executado. Adicione a FIRE_TRIGGERS opção para que o Sincronização de Dados possa rastrear esses inserts.
  • 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 replicação transacional

Sincronização de Dados Replicação transacional
Vantagens – Suporte ativo-ativo
- Bidirecional entre o ambiente local e o Banco de Dados SQL do Azure		 – 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

Cuidado

A Sincronização de Dados SQL requer autenticação SQL para conexões com os bancos de dados de hub e membro. A autenticação do Microsoft Entra ID não é suportada pelo SQL Sincronização de Dados.

Como a autenticação SQL depende de senhas estáticas, ela não se beneficia de proteções modernas como autenticação multifator (MFA), Acesso Condicional ou identidades gerenciadas. Essa dependência pode aumentar a exposição de toda a instância SQL a roubo de credenciais, ataques brutos e sobrecarga operacional para rotação de senhas e aplicação de políticas.

Sempre que possível, prefira soluções que dão suporte à autenticação ou identidades gerenciadas do Microsoft Entra. Como o SQL Sincronização de Dados está programado para aposentadoria, migre para uma alternativa que esteja alinhada com os padrões de segurança da sua organizaçã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. No Sincronização de Dados, o endpoint privado gerenciado pelo serviço é criado pela Microsoft e é usado exclusivamente pelo serviço 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

Consistência eventual

Como o Sincronização de Dados é baseado em gatilhos, ele não garante consistência transacional. A Microsoft garante que o Sincronização de Dados eventualmente faça todas as alterações e não cause 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 seu plano de serviço e faça a atualização necessária.

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 resulta no seguinte comportamento defeituoso:

  • Os dados entre o hub e o membro podem ser perdidos mesmo que a sincronização não reporte nenhum problema.
  • A sincronização pode falhar porque a tabela de rastreamento tem uma linha inexistente da fonte devido à mudança 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 Sincronização de Dados, tanto o banco de dados membro quanto o hub devem estar hospedados no Azure (na mesma região ou em regiões diferentes), no mesmo tipo de nuvem (por exemplo, tanto na nuvem pública quanto na nuvem governamental). Além disso, registre os provedores de recursos Microsoft.Network para as assinaturas que hospedam o hub e os servidores membros. Você deve aprovar manualmente o link privado para Sincronização de Dados durante a configuração de sincronização, na seção de conexões de endpoint privado no portal Azure ou via PowerShell. Para mais informações sobre como aprovar o link privado, veja o Tutorial: Configurar SQL Sincronização de Dados entre bancos de dados no Banco de Dados SQL do Azure e SQL Server. Depois que você aprova o endpoint privado gerenciado pelo serviço, toda a comunicação entre o serviço de sincronização e os bancos de dados membros/hubs ocorre pelo link privado. Você pode atualizar os grupos de sincronização existentes para ativar esse recurso.

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 esquemas diferentes (por exemplo, dbo.customers e sales.customers), você pode adicionar apenas uma das tabelas ao grupo de 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 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.
  • Sincronização de Dados suporta apenas as seguintes duas propriedades de índice: Único, Clusterizado/Não Clusterizado. 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 do Azure não pode ser usado como o banco de dados de metadados do SQL Sincronização de Dados e vice-versa.
  • A Sincronização de Dados SQL não tem suporte para bancos de dados do razão.
  • Sincronização de Dados não é uma ferramenta de recuperação de desastres ou alta disponibilidade, e não sincroniza suas próprias informações de grupo de sincronização. Não existe recuperação automática de desastres para o Sincronização de Dados.
  • O Sincronização de Dados não suporta perímetro de segurança de rede por design. O Sincronização de Dados funciona como um serviço de proxy, em vez de um recurso do Azure, portanto não possui um nome de domínio totalmente qualificado nem um endereço IP com base no qual definir regras de perímetro. Um perímetro bloqueia os caminhos de rede que o Sincronização de Dados exige tanto no modo transição quanto no modo forçado, e nenhuma regra de acesso faz isso funcionar. Se seu servidor lógico estiver associado a um perímetro, migre para uma solução de movimentação de dados que suporte perímetros de segurança de rede.

Tipos de dados sem suporte

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

Tipos de coluna não suportados

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 banco de dados, tabela, esquema e coluna 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

Pode 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 endpoints em todos os grupos de sincronização não pode ultrapassar 30. Se um banco de dados pertence a vários grupos de sincronização, ele conta como vários endpoints, não como um.

Requisitos de rede

Observação

Se você usa o link privado Sync, esses requisitos de rede não se aplicam.

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ê mudar as configurações de esquema do grupo de sincronização, precisa permitir que o serviço Sincronização de Dados acesse o servidor novamente para que o banco de dados 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.

Uma conta do Banco de Dados SQL do Azure é necessária?

Sim. Você deve ter uma conta do Banco de Dados SQL do Azure para hospedar o banco de dados do 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.
  • O Link Privado não é compatível em cenários entre locatários.

É 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)?

Sincronização de Dados não suporta sincronização entre nuvens.

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 usa Criptografia em Nível de Coluna (CLE), você pode sincronizar a coluna, desde que o tamanho da linha seja inferior ao 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?

Você pode usar um banco de dados raiz de federação com SQL Sincronização de Dados sem limitações. Você não pode adicionar o endpoint federado do banco de dados à versão atual do SQL Sincronização de Dados.

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?

A Sincronização de Dados SQL não oferece recursos automáticos de failover ou recuperação de desastres. Se o banco de dados sofrer failover para outra região, o grupo de sincronização deixa de funcionar. Recrie manualmente o grupo de sincronização na região de failover com as mesmas configurações da região principal.

Conteúdo relacionado

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 o Banco de Dados SQL do Azure, veja os seguintes artigos:

  • Last updated on