Partilhar via

Práticas recomendadas para o Azure SQL Data Sync

  • Artigo

Aplica-se a: do Banco de Dados SQL do Azure

Importante

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

Este artigo descreve as práticas recomendadas para o Azure SQL Data Sync.

Para obter uma visão geral da Sincronização de Dados SQL, consulte O que é a Sincronização de Dados SQL para Azure?

Segurança e fiabilidade

Agente cliente

  • Instale o agente cliente usando a conta de usuário menos privilegiada que tenha acesso ao serviço de rede.
  • Instale o agente cliente em um servidor diferente de onde o SQL Server está instalado.
  • Não registre um banco de dados local com mais de um agente.
    • Evite isso mesmo se estiver sincronizando tabelas diferentes para grupos de sincronização diferentes.
    • Registrar um banco de dados local com vários agentes cliente representa desafios quando você exclui um dos grupos de sincronização.

Contas de banco de dados com privilégios menos necessários

  • Para a configuração de sincronização:

    • Permissões do SQL Server: CRIAR/ALTERAR TABELA, ALTERAR BANCO DE DADOS, CRIAR PROCEDIMENTO, SELECIONAR/ALTERAR ESQUEMA, CRIAR TIPO. Essas permissões são incluídas (junto com outras permissões) na função de banco de dados interna ddl_admin.
    • No nível do grupo de recursos, a associação à função de Colaborador do Banco de Dados SQL é necessária. Para obter mais informações, consulte Atribuir funções do Azure usando o portal do Azure. A associação a funções mais amplas, como Contribuinte ou Proprietário, também funciona, se já estiver atribuída.
    • As permissões no nível de assinatura não devem ser necessárias, mas podem fornecer uma maneira simplificada (embora não menos necessária) de fornecer as permissões necessárias para várias implementações do Azure Data Sync em uma assinatura. Uma API de origem, agora obsoleta, exigia essas permissões RBAC do Azure, mas não deve mais ser utilizada.
      • "Microsoft.Sql/locations/syncMemberOperationResults/read"
      • "Microsoft.Sql/locations/syncAgentOperationResults/read"
      • "Microsoft.Sql/locations/syncGroupOperationResults/read"

  • Para sincronização contínua.

    • Permissões do SQL Server: permissão SELECT, INSERT, UPDATE e DELETE em tabelas de usuário selecionadas para sincronização. Permissão EXECUTE em tipos de tabela definidos pelo usuário.
    • Permissões do SQL Server: permissões de SELECT, INSERT, UPDATE e DELETE em metadados de sincronização e tabelas de rastreamento criadas pelo sistema. Permissão para EXECUTAR em procedimentos armazenados criados pelo serviço.
      • O esquema DataSync é usado para objetos criados pelo sistema nos bancos de dados hub e membro.
      • Os esquemas dss e TaskHosting são usados para objetos criados pelo sistema no banco de dados de metadados de sincronização.

  • Para desprovisionamento.

    • Permissões do SQL Server: ALTER em todas as tabelas que fazem parte da sincronização; SELECT e DELETE em tabelas de metadados de sincronização; CONTROLE em tabelas de rastreamento de sincronização, procedimentos armazenados e tipos definidos pelo usuário.
    • Para limpeza, remova objetos criados pelo sistema nos esquemas DataSync, dsse TaskHosting.

O Banco de Dados SQL do Azure dá suporte a apenas um único conjunto de credenciais. Para realizar essas tarefas dentro dessa restrição, considere as seguintes opções:

  • Altere as credenciais para diferentes fases (por exemplo, credenciais1 para configuração e credenciais2 para ongoing).
  • Altere a permissão das credenciais (ou seja, altere a permissão após a configuração da sincronização).

Auditoria

Recomenda-se habilitar a auditoria no nível dos bancos de dados nos grupos de sincronização. Saiba como habilitar a auditoria em seu banco de dados SQL do Azure ou habilitar a auditoria em seu banco de dados do SQL Server.

Configuração

Considerações e restrições do banco de dados

Tamanho do banco de dados

Ao criar um novo banco de dados, defina o tamanho máximo para que ele seja sempre maior do que o banco de dados implantado. Se você não definir o tamanho máximo como maior que o banco de dados implantado, a sincronização falhará. Embora a Sincronização de Dados SQL não ofereça crescimento automático, você pode executar o comando ALTER DATABASE para aumentar o tamanho do banco de dados depois que ele for criado. Certifique-se de permanecer dentro dos limites de tamanho do banco de dados.

Importante

A Sincronização de Dados SQL armazena metadados adicionais com cada banco de dados. Certifique-se de levar em conta esses metadados ao calcular o espaço necessário. A quantidade de sobrecarga adicionada está relacionada à largura das tabelas (por exemplo, tabelas estreitas exigem mais sobrecarga) e à quantidade de tráfego.

Considerações e restrições da tabela

Selecionar tabelas

Não é necessário incluir todas as tabelas que estão em um banco de dados em um grupo de sincronização. As tabelas incluídas em um grupo de sincronização afetam a eficiência e os custos. Inclua tabelas e as tabelas das quais elas dependem em um grupo de sincronização somente se as necessidades comerciais exigirem.

Chaves primárias

Cada tabela em um grupo de sincronização deve ter uma chave primária. A Sincronização de Dados SQL não pode sincronizar uma tabela que não tenha uma chave primária.

Antes de usar a Sincronização de Dados SQL na produção, teste o desempenho da sincronização inicial e contínua.

Mesas vazias proporcionam o melhor desempenho

As tabelas vazias fornecem o melhor desempenho no momento da inicialização. Se a tabela de destino estiver vazia, a Sincronização de Dados usará a inserção em massa para carregar os dados. Caso contrário, a Sincronização de Dados fará uma comparação e inserção linha a linha para verificar conflitos. No entanto, se o desempenho não for uma preocupação, você poderá configurar a sincronização entre tabelas que já contêm dados.

Provisionar bancos de dados de destino

A Sincronização de Dados SQL fornece provisionamento automático de banco de dados básico.

Esta seção discute as limitações do provisionamento no SQL Data Sync.

Limitações do provisionamento automático

A Sincronização de Dados SQL tem as seguintes limitações para o provisionamento automático:

  • Selecione apenas as colunas criadas na tabela de destino. As colunas que não fazem parte do grupo de sincronização não são provisionadas nas tabelas de destino.
  • Os índices são criados apenas para colunas selecionadas. Se o índice da tabela de origem tiver colunas que não fazem parte do grupo de sincronização, esses índices não serão provisionados nas tabelas de destino.
  • Os índices em colunas de tipo XML não são provisionados.
  • A Sincronização de Dados suporta apenas as duas propriedades de índice a seguir: Exclusivo, Clusterizado/Não Clusterizado. Outras propriedades do índice como IGNORE_DUP_KEY, filtro Where, etc., não são suportadas e o índice de destino é provisionado sem essas propriedades, mesmo que o índice de origem tenha essas propriedades definidas.
  • As restrições CHECK não são configuradas.
  • Os gatilhos existentes nas tabelas de origem não são provisionados.
  • Exibições e procedimentos armazenados não são criados no banco de dados de destino.
  • As ações ON UPDATE CASCADE e ON DELETE CASCADE aplicadas a restrições de chave estrangeira não são recriadas nas tabelas de destino.
  • Se você tiver colunas decimais ou numéricas com uma precisão maior que 28, a Sincronização de Dados SQL poderá encontrar um problema de estouro de conversão durante a sincronização. Recomendamos que você limite a precisão de colunas decimais ou numéricas a 28 ou menos.

Recomendações

  • Use o recurso de provisionamento automático da Sincronização de Dados SQL somente quando estiver testando o serviço.
  • Para produção, provisione o esquema de banco de dados.

Onde localizar o banco de dados do hub

Cenário de empresa para nuvem

Para minimizar a latência, mantenha o banco de dados do hub próximo à maior concentração do tráfego do banco de dados do grupo de sincronização.

Cenário de nuvem para nuvem

  • Quando todos os bancos de dados em um grupo de sincronização estão em um datacenter, o hub deve estar localizado no mesmo datacenter. Essa configuração reduz a latência e o custo da transferência de dados entre datacenters.
  • Quando os bancos de dados em um grupo de sincronização estão em vários datacenters, o hub deve estar localizado no mesmo datacenter que a maioria dos bancos de dados e do tráfego do banco de dados.

Cenários mistos

Aplique as diretrizes anteriores a configurações complexas de grupos de sincronização, como aquelas que são uma combinação de cenários de empresa para nuvem e de nuvem para nuvem.

Sincronização

Evite a sincronização inicial lenta e dispendiosa

Nesta seção, discutimos a sincronização inicial de um grupo de sincronização. Saiba como ajudar a evitar que uma sincronização inicial demore mais tempo e seja mais cara do que o necessário.

Como funciona a sincronização inicial

Ao criar um grupo de sincronização, comece com dados em apenas um banco de dados. Se você tiver dados em vários bancos de dados, a Sincronização de Dados SQL tratará cada linha como um conflito que precisa ser resolvido. Essa resolução de conflitos faz com que a sincronização inicial vá lentamente. Se você tiver dados em vários bancos de dados, a sincronização inicial pode levar entre vários dias e vários meses, dependendo do tamanho do banco de dados.

Se os bancos de dados estiverem em datacenters diferentes, cada linha deverá viajar entre os diferentes datacenters. Isso aumenta o custo de uma sincronização inicial.

Recomendação

Se possível, comece com dados em apenas um dos bancos de dados do grupo de sincronização.

Design para evitar loops de sincronização

Um loop de sincronização ocorre quando há referências circulares dentro de um grupo de sincronização. Nesse cenário, cada alteração em um banco de dados é replicada infinita e circularmente através dos bancos de dados no grupo de sincronização.

Certifique-se de evitar loops de sincronização, pois eles causam degradação do desempenho e podem aumentar significativamente os custos.

Alterações que não se propagam

Razões pelas quais as mudanças não se propagam

As alterações podem não se propagar por um dos seguintes motivos:

  • Incompatibilidade de esquema/tipo de dados.
  • Inserção de null em colunas não anuláveis.
  • Violar restrições de chave estrangeira.

O que acontece quando as alterações não se propagam?

  • O grupo de sincronização mostra que está em um estado de aviso.
  • Os detalhes são listados no visualizador de log da interface do usuário do portal.
  • Se o problema não for resolvido por 45 dias, o banco de dados ficará desatualizado.

Observação

Estas mudanças nunca se propagam. A única maneira de recuperar nesse cenário é recriar o grupo de sincronização.

Recomendação

Monitore o grupo de sincronização e a integridade do banco de dados regularmente por meio do portal e da interface de log.

Manutenção

Evite bancos de dados desatualizados e grupos de sincronização

Um grupo de sincronização ou um banco de dados em um grupo de sincronização pode ficar desatualizado. Quando o status de um grupo de sincronização é desatualizado, ele para de funcionar. Quando o status de um banco de dados é desatualizado, os dados podem ser perdidos. É melhor evitar esse cenário em vez de tentar se recuperar dele.

Evite bancos de dados desatualizados

O status de um banco de dados é definido como Desatualizado quando estiver offline por 45 dias ou mais. Para evitar um status de desatualizado em um banco de dados, verifique se nenhum dos bancos de dados está offline por 45 dias ou mais.

Evite grupos de sincronização desatualizados

O status de um grupo de sincronização é definido como Desatualizado quando qualquer alteração no grupo de sincronização não se propaga para o restante do grupo de sincronização por 45 dias ou mais. Para evitar um status de desatualizado em um grupo de sincronização, verifique regularmente o registro de histórico do grupo de sincronização. Certifique-se de que todos os conflitos sejam resolvidos e que as alterações sejam propagadas com êxito pelos bancos de dados do grupo de sincronização.

Um grupo de sincronização pode não conseguir aplicar uma alteração por um destes motivos:

  • Incompatibilidade de esquema entre tabelas.
  • Incompatibilidade de dados entre tabelas.
  • Inserir uma linha com um valor nulo em uma coluna que não permite valores nulos.
  • Atualizar uma linha com um valor que viola uma restrição de chave estrangeira.

Para evitar grupos de sincronização desatualizados:

  • Atualize o esquema para permitir os valores contidos nas linhas com falha.
  • Atualize os valores de chave estrangeira para incluir os valores contidos nas linhas com falha.
  • Atualize os valores de dados na linha com falha para que sejam compatíveis com o esquema ou chaves estrangeiras no banco de dados de destino.

Evite problemas de desprovisionamento

Em algumas circunstâncias, cancelar o registro de um banco de dados com um agente cliente pode fazer com que a sincronização falhe.

Cenário

  1. O grupo de sincronização A foi criado usando uma instância do Banco de dados SQL e um banco de dados do SQL Server, que está associado ao agente local 1.
  2. O mesmo banco de dados local é registrado com o agente local 2 (esse agente não está associado a nenhum grupo de sincronização).
  3. Cancelar o registro do banco de dados local do agente local 2 remove as tabelas de controle e meta do grupo de sincronização A para o banco de dados local.
  4. As operações do grupo de sincronização A falham, com este erro: "A operação atual não pôde ser concluída porque o banco de dados não está provisionado para sincronização ou você não tem permissões para as tabelas de configuração de sincronização."

Solução

Para evitar esse cenário, não registre um banco de dados com mais de um agente.

Para recuperar deste cenário:

  1. Remova o banco de dados de cada grupo de sincronização ao qual ele pertence.
  2. Adicione o banco de dados novamente a cada grupo de sincronização do qual você o removeu.
  3. Implante cada grupo de sincronização afetado (esta ação provisiona o banco de dados).

Modificar um grupo de sincronização

Não tente remover um banco de dados de um grupo de sincronização e, em seguida, edite o grupo de sincronização sem primeiro implantar uma das alterações.

Em vez disso, primeiro remova um banco de dados de um grupo de sincronização. Em seguida, implante a alteração e aguarde a conclusão do desprovisionamento. Quando o desprovisionamento estiver concluído, você poderá editar o grupo de sincronização e implantar as alterações.

Se você tentar remover um banco de dados e, em seguida, editar um grupo de sincronização sem primeiro implantar uma das alterações, uma ou outra operação falhará. A interface do portal pode tornar-se inconsistente. Se isso acontecer, atualize a página para restaurar o estado correto.

Evitar o tempo limite de atualização do esquema

Se você tiver um esquema complexo para sincronizar, poderá encontrar um "tempo limite de operação" durante uma atualização de esquema se o banco de dados de metadados de sincronização tiver uma SKU menor (exemplo: básico).

Solução

Para atenuar esse problema, considere expandir os recursos do banco de dados de metadados de sincronização.

Conteúdo relacionado

Para obter mais informações sobre o SQL Data Sync, consulte:

Para obter mais informações sobre o Banco de dados SQL, consulte: