Partager via

Bonnes pratiques pour Azure SQL Data Sync

  • Article

S’applique à : Azure SQL Database

Important

SQL Data Sync sera mis hors service le 30 septembre 2027. Envisagez de migrer vers d’autres solutions de réplication/synchronisation de données.

Cet article décrit les bonnes pratiques relatives à Azure SQL Data Sync.

Pour une vue d’ensemble de SQL Data Sync, consultez la Présentation de SQL Data Sync pour Azure.

Sécurité et fiabilité

Agent client

  • Installez l’agent client à l’aide du compte d'utilisateur doté des moindres privilèges ayant accès aux services réseau.
  • Installez l’agent client sur un serveur différent de celui où SQL Server est installé.
  • N’inscrivez pas une base de données sur site auprès de plusieurs agents,
    • Même si vous synchronisez différentes tables pour différents groupes de synchronisation.
    • L’inscription d’une base de données sur site auprès de plusieurs agents clients risque de poser des problèmes lors de la suppression de l’un des groupes de synchronisation.

Comptes de base de données avec le moins de privilèges nécessaires

  • Pour la configuration de la synchronisation :

    • Autorisations SQL Server : CREATE/ALTER TABLE, ALTER DATABASE, CREATE PROCEDURE, SELECT/ALTER SCHEMA, CREATE TYPE. Ces autorisations (ainsi que d’autres) sont incluses dans le rôle de base de données intégré ddl_admin.
    • Au niveau du groupe de ressources, l’appartenance au rôle Contributeur de base de données SQL est nécessaire. Pour plus d’informations, consultez Attribuer des rôles Azure en utilisant le portail Azure. L’appartenance à des rôles plus larges, tels que Contributeur ou Propriétaire, fonctionne également, si elle est déjà attribuée.
    • Des autorisations au niveau abonnement ne devraient pas être nécessaires, mais pourraient offrir un moyen simplifié (bien que le moins requis) de fournir les autorisations nécessaires pour plusieurs implémentations d’Azure Data Sync dans un abonnement. Une API originale, désormais déconseillée, nécessitait ces autorisations RBAC Azure, mais ne devrait plus être utilisée.
      • "Microsoft.Sql/locations/syncMemberOperationResults/read"
      • "Microsoft.Sql/locations/syncAgentOperationResults/read"
      • "Microsoft.Sql/locations/syncGroupOperationResults/read"

  • Pour la synchronisation continue.

    • Autorisations SQL Server : autorisations SELECT, INSERT, UPDATE et DELETE sur des tables utilisateur sélectionnées pour synchronisation. Autorisation EXECUTE sur des types de tables définis par l’utilisateur.
    • Autorisations SQL Server : autorisations SELECT, INSERT, UPDATE et DELETE sur des métadonnées de synchronisation et des tables de suivi créées par le système. Autorisation EXECUTE sur des procédures stockées créées par le service.
      • Le schéma DataSync est utilisé pour des objets créés par le système dans les bases de données du hub et des membres.
      • Les schémas et dss les TaskHosting sont utilisés pour des objets créés par le système dans la base de données de métadonnées de synchronisation.

  • Pour annuler le provisionnement.

    • Autorisations SQL Server : ALTER sur toutes des tables faisant partie de la synchronisation ; SELECT et DELETE sur des tables de métadonnées de synchronisation ; CONTROL sur des tables de suivi de synchronisation, des procédures stockées et des types définis par l’utilisateur.
    • Pour le nettoyage, supprimez les objets créés par le système dans les schémas et DataSync, dss et TaskHosting.

Azure SQL Database ne prend en charge qu'un seul ensemble d'informations d'identification. Pour accomplir ces tâches avec cette contrainte, prenez en compte les options suivantes :

  • Changez les informations d’identification pour différentes phases (par exemple, credentials1 pour la configuration et credentials2 pour les opérations continues).
  • Modifiez l’autorisation des informations d’identification (autrement dit, modifiez l’autorisation après avoir configuré la synchronisation).

Audit

Il est recommandé d’activer l’audit au niveau des bases de données dans les groupes de synchronisation. Découvrez comment activer l’audit sur votre base de données Azure SQL ou activer l’audit sur votre base de données de SQL Server.

Programme d’installation

Considérations et contraintes relatives aux bases de données

Taille de la base de données

Quand vous créez une base de données, définissez la taille maximale afin qu’elle soit toujours supérieure à la base de données que vous déployez. Si vous n’affectez pas à la taille maximale une valeur supérieure à la base de données déployée, la synchronisation échoue. Bien que SQL Data Sync n’offre pas de croissance automatique, vous pouvez exécuter la commande ALTER DATABASE pour augmenter la taille de la base de données après sa création. Veillez à rester dans les limites de taille de la base de données.

Important

SQL Data Sync stocke des métadonnées supplémentaires avec chaque base de données. Veillez à prendre en compte ces métadonnées quand vous calculez l’espace nécessaire. La quantité de surcharge ajoutée est régie par la largeur des tables (par exemple, des tables étroites nécessitent davantage de surcharge) et la quantité de trafic.

Considérations et contraintes relatives aux tables

Sélectionner des tables

Vous n'avez pas besoin d'inclure toutes les tables figurant dans une base de données d'un groupe de synchronisation. Les tables que vous incluez dans un groupe de synchronisation affectent l'efficacité et les coûts. Incluez les tables (et les tables dont elles dépendent) dans un groupe de synchronisation uniquement si les besoins de l'entreprise l'exigent.

Clés primaires

Chaque table dans un groupe de synchronisation doit avoir une clé primaire. SQL Data Sync ne peut pas synchroniser une table qui n’a pas de clé primaire.

Avant d’utiliser SQL Data Sync en production, testez les performances de synchronisation initiales et actuelles.

Les tables vides optimisent les performances

Les tables vides offrent les meilleures performances au moment de l’initialisation. Si la table cible est vide, Data Sync utilise l’insertion en bloc pour charger les données. Dans le cas contraire, Data Sync effectue une comparaison et une insertion ligne par ligne afin de rechercher les conflits. Toutefois, si les performances ne sont pas un critère important, vous pouvez configurer la synchronisation entre des tables qui contiennent déjà des données.

Provisionnement des bases de données de destination

SQL Data Sync fournit un provisionnement automatique de base des bases de données.

Cette section présente les limitations du provisionnement dans SQL Data Sync.

Limitations du provisionnement automatique

Voici les limitations du provisionnement automatique de SQL Data Sync :

  • Sélectionnez uniquement les colonnes créées dans la table de destination. Les colonnes qui ne font pas partie du groupe de synchronisation ne sont pas provisionnées dans les tables de destination.
  • Des index sont créés uniquement pour les colonnes sélectionnées. Si l’index de la table source a des colonnes qui ne font pas partie du groupe de synchronisation, ces index ne sont pas provisionnés dans les tables de destination.
  • Les index sur des colonnes de type XML ne sont pas provisionnés.
  • Data Sync ne prend en charge que les deux propriétés d’index suivantes : Unique, En cluster/Non cluster. Les autres propriétés d’index, comme IGNORE_DUP_KEY, le prédicat de filtre Where, etc. ne sont pas pris en charge et l’index de destination est provisionné sans ces propriétés, même si ces propriétés sont définies pour l’index source.
  • Les contraintes CHECK ne sont pas provisionnées.
  • Les déclencheurs existants sur les tables sources ne sont pas provisionnés.
  • Les vues et procédures stockées ne sont pas créées sur la base de données de destination.
  • Les actions ON UPDATE CASCADE and ON DELETE CASCADE sur les contraintes de clé étrangère ne sont pas recréées dans les tables de destination.
  • Si vous avez des colonnes de type décimal ou numérique avec une précision supérieure à 28, SQL Data Sync pourrait être l’objet d’un dépassement de capacité en matière de conversion au cours de la synchronisation. Nous vous recommandons de limiter la précision des colonnes de type décimal ou numérique à 28 ou moins.

Recommandations

  • Utilisez la fonctionnalité de provisionnement automatique de SQL Data Sync uniquement quand vous testez le service.
  • Pour la production, provisionnez le schéma de base de données.

Emplacement de la base de données Hub

Scénario entreprise-à-cloud

Pour réduire la latence, conservez la base de données Hub proche de la plus grande concentration du trafic de base de données du groupe de synchronisation.

Scénario cloud-à-cloud

  • Quand toutes les bases de données d’un groupe de synchronisation sont dans un même centre de données, le hub doit se trouver dans le même centre de données. Cette configuration réduit la latence et le coût de transfert de données entre les centres de données.
  • Quand les bases de données d’un groupe de synchronisation se trouvent dans plusieurs centres de données, le hub doit se trouver dans le même centre de données que la majorité des bases de données et du trafic de base de données.

Scénarios mixtes

Appliquez les instructions précédentes aux configurations de groupe de synchronisation complexes, notamment celles qui combinent des scénarios entreprise-à-cloud et cloud-à-cloud.

Synchronisation

Éviter une synchronisation initiale lente et coûteuse

Cette section aborde la synchronisation initiale d'un groupe de synchronisation. Découvrez comment éviter qu'une synchronisation initiale prenne plus de temps et soit plus coûteuse que nécessaire.

Fonctionnement de la synchronisation initiale

Quand vous créez un groupe de synchronisation, commencez avec des données d’une seule base de données. Si vous avez des données dans plusieurs bases de données, SQL Data Sync traite chaque ligne comme un conflit à résoudre. Cette résolution de conflit entraîne une lente synchronisation initiale. Si vous avez des données dans plusieurs bases de données, la synchronisation initiale peut prendre plusieurs jours voire plusieurs mois, en fonction de la taille de la base de données.

Si les bases de données se trouvent dans des centres de données différents, chaque ligne doit se déplacer entre ces différents centres de données. Cela augmente le coût d'une synchronisation initiale.

Recommandation

Si possible, commencez avec les données d’une seule des bases de données du groupe de synchronisation.

Conception permettant d'éviter des boucles de synchronisation

Une boucle de synchronisation se produit lorsqu'un groupe de synchronisation contient des références circulaires. Dans ce scénario, chaque modification dans une base de données est répliquée sans fin et de façon circulaire dans toutes les bases de données du groupe de synchronisation.

Veillez à éviter les boucles de synchronisation, car elles entraînent une dégradation des performances et peuvent considérablement augmenter les coûts.

Modifications dont la propagation échoue

Raisons pour lesquelles la propagation des modifications échoue

La propagation des modifications peut échouer pour l'une des raisons suivantes :

  • Incompatibilité de schéma/type de données
  • Insertion de valeurs null dans des colonnes non nullables
  • Violation de contraintes de clé étrangère

Que se passe-t-il quand la propagation des modifications échoue ?

  • Le groupe de synchronisation affiche un état d’avertissement.
  • Les détails sont affichés dans la visionneuse du journal de l’interface utilisateur du portail.
  • Si le problème n’est pas résolu pendant 45 jours, la base de données devient obsolète.

Notes

Ces modifications ne sont jamais propagées. Dans ce scénario, la seule façon de récupérer consiste à recréer le groupe de synchronisation.

Recommandation

Surveillez l’intégrité du groupe de synchronisation et de la base de données régulièrement par le biais de l’interface du portail et du journal.

Maintenance

Éviter les bases de données et les groupes de synchronisation obsolètes

Un groupe de synchronisation ou une base de données d’un groupe de synchronisation peut devenir obsolète. Quand l’état d’un groupe de synchronisation est obsolète, il cesse de fonctionner. Quand l’état d’une base de données est obsolète, il y a un risque de perte de données. Il est préférable d'éviter ce scénario plutôt que de tenter de le récupérer.

Éviter les bases de données obsolètes

Une base de données bascule à l’état obsolète quand elle est hors connexion depuis 45 jours ou plus. Pour éviter qu’une base de données ne bascule à l’état obsolète, veillez à ce qu’aucune des bases de données ne soit hors connexion pendant 45 jours ou plus.

Éviter les groupes de synchronisation obsolètes

Un groupe de synchronisation bascule à l’état obsolète en cas d’échec de propagation d’une modification dans le groupe de synchronisation vers le reste du groupe de synchronisation pendant 45 jours ou plus. Pour éviter qu’un groupe de synchronisation ne bascule à l’état obsolète, vérifiez régulièrement le journal d’historique du groupe de synchronisation. Assurez-vous que tous les conflits sont résolus et que les modifications sont propagées dans les bases de données du groupe de synchronisation.

Un groupe de synchronisation peut échouer à appliquer une modification pour l'une des raisons suivantes :

  • Incompatibilité de schéma entre des tables
  • Incompatibilité de données entre des tables
  • Insertion d’une ligne avec une valeur null dans une colonne qui n’autorise pas les valeurs null
  • Mise à jour d’une ligne avec une valeur qui enfreint une contrainte de clé étrangère

Pour empêcher qu’un groupe de synchronisation ne devienne obsolète :

  • Mettez à jour le schéma pour autoriser les valeurs contenues dans les lignes ayant provoqué l’échec.
  • Mettez à jour les valeurs de clé étrangères pour inclure les valeurs contenues dans les lignes ayant provoqué l’échec.
  • Mettez à jour les valeurs de données dans la ligne ayant provoqué l’échec pour qu’elles soient compatibles avec le schéma ou les clés étrangères dans la base de données cible.

Éviter les problèmes d’annulation du provisionnement

Dans certaines circonstances, la désinscription d’une base de données auprès d’un agent client peut entraîner l’échec de la synchronisation.

Scénario

  1. Le groupe de synchronisation A a été créé avec une instance de SQL Database et une base de données SQL Server, qui est associée à l’agent local 1.
  2. La même base de données locale est inscrite auprès de l’agent local 2 (cet agent n’est associé à aucun groupe de synchronisation).
  3. Si vous annulez l’inscription de la base de données sur site auprès de l’agent local 2, cela supprime les tables de suivi et métadonnées pour le groupe de synchronisation A pour la base de données sur site.
  4. Les opérations du groupe de synchronisation A échouent avec cette erreur : « L’opération en cours a échoué, car la base de données n’est pas provisionnée pour la synchronisation ou vous n’avez pas les autorisations nécessaires sur les tables de configuration de synchronisation. »

Solution

Pour éviter ce scénario, n'inscrivez pas une base de données auprès de plusieurs agents.

Pour résoudre ce problème :

  1. Supprimez la base de données de chaque groupe de synchronisation auquel elle appartient.
  2. Rajoutez la base de données dans chaque groupe de synchronisation où vous venez de la retirer.
  3. Déployez chaque groupe de synchronisation concerné (cette action provisionne la base de données).

Modifiez un groupe de synchronisation

N’essayez pas de supprimer une base de données d’un groupe de synchronisation et de modifier ensuite le groupe de synchronisation sans avoir déployé au préalable l’une des modifications.

Supprimez d'abord une base de données d’un groupe de synchronisation. Ensuite, déployez la modification et attendez que l’annulation du provisionnement soit terminée. Une fois l'annulation du provisionnement terminée, vous pouvez modifier le groupe de synchronisation et déployer les modifications.

Si vous tentez de supprimer une base de données et de modifier un groupe de synchronisation sans avoir déployé au préalable l’une des modifications, l’une ou l’autre opération échoue. L’interface du portail peut basculer dans un état incohérent. Dans ce cas, actualisez la page pour restaurer l’état correct.

Éviter le délai d’expiration de l’actualisation du schéma

Si vous avez un schéma complexe à synchroniser, vous risquez de rencontrer une erreur du type « l’opération a expiré » pendant l’actualisation du schéma si la base de données de métadonnées de synchronisation a une référence SKU inférieure (exemple : De base).

Solution

Pour atténuer ce problème, envisagez de mettre à l’échelle vos ressources de base de données de métadonnées de synchronisation.

Contenu connexe

Pour plus d’informations sur SQL Data Sync, consultez :

Pour plus d’informations sur SQL Database, consultez :