Réplication bidirectionnelle
La réplication bidirectionnelle dans (IDR) permet aux données de circuler d’une Réplication de données d'instance instance de créateur vers une instance de consommateur et d’accepter les données d’une instance de consommateur pour qu’elles soient renvoyées à l’instance du producteur.
Toutes les insertions et changements apportés aux enregistrements sur une instance sont envoyés à l’autre instance pour que les tables restent identiques sur les deux instances. Par exemple, vous pouvez activer la réplication bidirectionnelle pour la table Incidents afin de synchroniser les enregistrements d’incidents entre deux instances.
Pour que les données circulent de manière bidirectionnelle, le système crée un ensemble de réplications du producteur sur l’instance du consommateur et un ensemble de réplications du consommateur sur l’instance du producteur.
Si vous examinez les ensembles de réplications sur l’instance du producteur d’origine, vous voyez le nom de l’ensemble de réplications et l’instance de consommateur générée automatiquement. Il porte le même nom auquel est ajouté le suffixe -<long-number>-reverse, où <long-number> est un nombre généré aléatoirement. Par exemple, si Test est le nom de l’ensemble de réplications du producteur, Test-2034802-reverse peut être le nom de l’ensemble de réplications du consommateur qui est automatiquement créé sur la même instance. Sur l’instance de consommateur d’origine, les mêmes noms s’affichent. Les ensembles de réplications avec le suffixe inverse sont en lecture seule.
Vous pouvez vérifier un consommateur sur une instance de producteur et un producteur sur une instance de consommateur en exécutant https://<producer-instance-name>/xmlstats.do ?include=idr et https://<consumer-instance-name>/xmlstats.do ?include=idr sur les instances de producteur et de consommateur. Dans l’image suivante, l’instance du producteur d’origine est à gauche et l’instance du consommateur d’origine est à droite.
- La résolution automatique des conflits n’est pas prise en charge.
- Les conflits de fusion se produisent si les instances de producteur et de consommateur modifient le même enregistrement en même temps.
La mise à jour la plus récente l’emporte, ce qui signifie que les données sur les tables des consommateurs et des producteurs peuvent être différentes.
- La réplication bidirectionnelle prend en charge l’adaptateur Number , mais aucune des autres adaptateurs.
- La réplication bidirectionnelle permet de synchroniser les données entre les instances du producteur et du consommateur. Toutefois, dans certains scénarios, évitez d’utiliser la réplication bidirectionnelle et utilisez plutôt la réplication unidirectionnelle.
- Si vous prévoyez d’utiliser des adaptateurs pour différencier les données répliquées entre deux instances, utilisez deux ensembles de réplication unidirectionnels pour répliquer les données dans les deux sens au lieu d’utiliser des ensembles bidirectionnels.
- Si vous avez besoin d’amorcer des données d’une instance à une autre et vice versa, utilisez deux ensembles de réplications unidirectionnels.
- Avec la réplication bidirectionnelle, les enregistrements créés sur l’instance du producteur sont répliqués sur une instance de consommateur et vice versa. Lorsque l’enregistrement est inséré sur l’instance de consommateur et qu’il déclenche une règle métier qui met à jour l’enregistrement, cette mise à jour n’est pas répliquée vers l’instance du créateur.
Si vous devez comprendre les implications de la bidirectionnellité et du transfert de données entre les instances, consultez Confidentialité des données dans IDR pour plus d’informations.