Melhores práticas da Sincronização de Dados SQL do Azure
Aplica-se a:Banco de Dados SQL do Azure
Este artigo descreve as práticas recomendadas para o Azure SQL Data Sync.
Para obter uma descrição geral da Sincronização de Dados SQL, veja Sincronizar dados em várias bases de dados na cloud e no local com a Sincronização de Dados SQL do Azure.
Importante
O Azure SQL Data Sync não oferece suporte à Instância Gerenciada SQL do Azure ou ao Azure Synapse Analytics no momento.
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 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
ddl_admin
de banco de dados interna. - 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, veja Utilizar o portal do Azure para atribuir funções do Azure. A associação a funções mais amplas, como Colaborador 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 importante) de fornecer as permissões necessárias para várias implementações do Azure Data Sync em uma assinatura. Uma API original e preterida exigia essas permissões do Azure RBAC, mas não deve mais estar em uso.
- "Microsoft.Sql/locations/syncMemberOperationResults/read"
- "Microsoft.Sql/locations/syncAgentOperationResults/read"
- "Microsoft.Sql/locations/syncGroupOperationResults/read"
- 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
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ão SELECT, INSERT, UPDATE e DELETE em metadados de sincronização e tabelas de controle criadas pelo sistema. Permissão EXECUTAR em procedimentos armazenados criados pelo serviço.
- O
DataSync
esquema é usado para objetos criados pelo sistema nos bancos de dados de hub e membro. - Os
dss
esquemas eTaskHosting
são usados para objetos criados pelo sistema no banco de dados de metadados de sincronização.
- 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 controle de sincronização, procedimentos armazenados e tipos definidos pelo usuário.
- Para limpeza, remova objetos criados pelo
DataSync
sistema nos esquemas,dss
eTaskHosting
.
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, credentials1 para configuração e credentials2 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.
Configurar
Considerações e restrições do banco de dados
Tamanho da base 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 para aumentar o ALTER DATABASE
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
Seleção de 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.
Provisionamento de 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 de índice como IGNORE_DUP_KEY, Onde filtro predicado 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 provisionadas.
- 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 sobre 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.
Sincronizar
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
Quando criar um grupo de sincronização, comece com os dados numa única base de dados. Se tiver dados em várias bases de dados, a Sincronização de Dados SQL trata cada linha como um conflito que precisa de 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.
Nota
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 está desatualizado, ele para de funcionar. Quando o status de um banco de dados está 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 ele estiver offline por 45 dias ou mais. Para evitar um status 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 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
- 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.
- O mesmo banco de dados local é registrado com o agente local 2 (esse agente não está associado a nenhum grupo de sincronização).
- Cancelar o registro do banco de dados local do agente local 2 remove as tabelas de controle e meta para o grupo de sincronização A para o banco de dados local.
- 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:
- Remova o banco de dados de cada grupo de sincronização ao qual ele pertence.
- Adicione o banco de dados novamente a cada grupo de sincronização do qual você o removeu.
- 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.
Próximos passos
Para obter mais informações sobre o SQL Data Sync, consulte:
- Visão geral - Sincronize dados em vários bancos de dados locais e na nuvem com o Azure SQL Data Sync
- Configurar a Sincronização de Dados SQL
- Agente de Sincronização de Dados - Agente de Sincronização de Dados para Sincronização de Dados SQL do Azure
- Monitor - Monitorar a sincronização de dados SQL com logs do Azure Monitor
- Solucionar problemas - Solucionar problemas com a Sincronização de Dados SQL do Azure
- Atualizar o esquema de sincronização
Para obter mais informações sobre o Banco de dados SQL, consulte: