Considérations sur la conception de fournisseur personnalisé standard
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 devez restaurer un magasin de données à partir d'une sauvegarde, vous devez tenir compte des problèmes suivants.
Les modifications 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 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 de source envoie des modifications à un fournisseur de destination. Le fournisseur de destination applique les modifications et met à jour sa connaissance. 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.
Lorsque le service de stockage des métadonnées est utilisé pour stocker des métadonnées, la modification de l'ID de réplica implique les étapes supplémentaires 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 de métadonnées. Placez le fournisseur de destination en mode restauration.
Synchroniser à partir du fournisseur de source vers le fournisseur de destination. Le magasin de métadonnées est ainsi rempli sous le nouvel ID de réplica.
Supprimer l'ancien magasin de métadonnées et utiliser le nouveau magasin de métadonnées et le nouvel ID de réplica pour représenter le replica. 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 sur les conflits de contraintes, consultez Détection et résolution des conflits de contraintes.