Considérations sur la conception de fournisseur personnalisé simple
Un magasin de données de production qui intervient dans la synchronisation doit être sauvegardé régulièrement, comme n'importe quel autre magasin de données. Si vous êtes amené à restaurer un magasin de données à partir d'une sauvegarde, vous devez tenir compte de deux éléments :
Les modifications qui ont été apportées dans le magasin de données après la restauration ne seront peut-être pas propagées à d'autres réplicas.
Ce cas peut se produire dans un fournisseur basé sur les ancres parce que l'ancre envoyée par le fournisseur de destination, que le fournisseur de source utilise pour énumérer des modifications, peut être logiquement après les modifications effectuées après la restauration. Par exemple, un fournisseur basé sur les ancres envoie des modifications à un fournisseur de destination, qui enregistre l'ancre utilisée pour énumérer les modifications. Le réplica source est restauré d'une sauvegarde antérieure et les modifications sont apportées. La synchronisation est encore effectuée avec les mêmes source et fournisseurs de destination. Le fournisseur de destination commence par envoyer l'ancre utilisée pendant la dernière synchronisation. Selon la façon dont l'ancre est construite, le fournisseur de source peut détecter que certaines des modifications effectuées après la restauration n'auraient pas dû être énumérées.
Cela peut également se produire dans un fournisseur d'énumération complète parce que le nombre de cycles utilisé pour attribuer des versions aux modifications sur le réplica source peut entraîner la détection de modifications comme étant obsolètes. Par exemple, un fournisseur d'énumération complète envoie des modifications à un fournisseur de destination. Le fournisseur de destination applique les modifications et met à jour sa connaissance interne. Le réplica source est restauré d'une sauvegarde antérieure, qui inclut un nombre de cycles antérieur. Les modifications apportées au réplica source sont des versions attribuées selon ce nombre de cycles antérieur. La synchronisation est à nouveau effectuée. Certaines des modifications énumérées à partir du fournisseur de source ont un nombre de cycles qui est contenu de manière incorrecte dans la connaissance de destination ; elles sont ainsi détectées comme étant obsolètes et ne sont pas appliquées au réplica de destination.
Afin de remédier à cette situation, il convient d'affecter un nouvel ID de réplica à chaque fois qu'un réplica est restauré à partir d'une sauvegarde. Le réplica restauré est traité comme étant un nouveau réplica qui a reçu toutes ses données du réplica sauvegardé, et le réplica sauvegardé est traité comme retiré de la communauté de synchronisation. D'autres réplicas de la communauté de synchronisation n'ont pas connaissance du réplica restauré en raison du nouvel ID de réplica ; ainsi, les nouveaux éléments ajoutés au réplica restauré sont correctement envoyés lors de la synchronisation.
Comme les fournisseurs personnalisés simples utilisent le service de stockage des métadonnées pour stocker les métadonnées, la modification de l'ID de réplica implique les étapes suivantes.
Implémenter le fournisseur afin qu'il puisse fonctionner dans un mode spécifique conçu pour restaurer à partir d'une sauvegarde. En mode restauration, le fournisseur de destination applique seulement les modifications de métadonnées au réplica de destination. Le fournisseur ne détecte pas les modifications locales et n'applique pas les données de modification au réplica.
Restaurer le réplica à partir d'une sauvegarde. Une fois que le réplica est restauré à partir d'une sauvegarde, créez deux instances du fournisseur. Le fournisseur de source représente le réplica restauré avec l'ancien ID de réplica, et le fournisseur de destination représente le réplica restauré avec un nouvel ID de réplica et un nouveau magasin des métadonnées. Placez le fournisseur de destination en mode restauration.
Synchroniser à partir du fournisseur de source vers le fournisseur de destination. Le magasin des métadonnées est ainsi rempli sous le nouvel ID de réplica.
Supprimer l'ancien magasin des métadonnées et utiliser le nouveau magasin des métadonnées et le nouvel ID de réplica pour représenter le réplica. Vous êtes maintenant prêt à synchroniser avec le reste de la communauté de synchronisation.
Les nouveaux éléments qui ont été créés après la restauration peuvent provoquer des collisions de noms lorsqu'un élément du même nom a été précédemment créé et synchronisé. Par exemple, un réplica source stocke des fichiers. Le fournisseur de source envoie une modification de création pour un fichier nommé « MyChange.txt ». Le réplica source est restauré à partir d'une sauvegarde antérieure qui ne contient pas MyChange.txt. Un nouveau fichier MyChange.txt est créé, auquel un nouvel ID d'élément est attribué par le fournisseur de source. La synchronisation est à nouveau effectuée. Lorsque la modification de MyChange.txt est envoyée, le fournisseur de destination détecte un conflit de contraintes entre les deux fichiers MyChange.txt, parce qu'ils ont le même nom, mais des ID d'éléments différents.
Afin de remédier à cette situation, il convient de gérer les conflits de contraintes dans le fournisseur. De cette façon, lorsque des collisions de noms se produisent, elles sont signalées en tant que conflits de contraintes et sont correctement résolues. Pour plus d'informations, consultez Gestion de conflits pour les fournisseurs simples.