Préparation pour Réplication de données d'instance
Avant de configurer Réplication de données d'instance (IDR), analysez les tables et les colonnes des instances de producteur et de consommateur pour reproduire les données avec succès.
Préparation de vos instances
Réduisez la latence en vous assurant que les instances producteur et consommateur se trouvent dans la même région géographique et appartiennent au même client. Vous pouvez répliquer des données entre des instances dans différentes régions géographiques. Toutefois, une latence de réplication peut se produire lorsque les instances sont situées dans des centres de données situés dans des régions distinctes.
Choix des tables à répliquer
Avant de créer un ensemble de réplications de producteur, déterminez les tables à répliquer. Évitez de répliquer les tables système (tables avec un préfixe sys_). Si vous répliquez des tables système (telles que sys_user, sys_user_group ou sys_user_grmember) qui ont des données existantes dans l’instance de consommateur, des échecs d’insertion et de mise à jour peuvent se produire pendant la réplication. Si vous décidez de répliquer ces tables, vous aurez peut-être un travail supplémentaire par la suite pour nettoyer ces tables.
Évitez la réplication continue des CMDB tables. La réplication des CMDB données au fur et à mesure des changements peut créer des problèmes de performances ou des conséquences imprévues avec la réplication en raison du nombre d’enregistrements impliqués. Si vous devez répliquer des CMDB tables, envisagez de planifier la réplication ou utilisez des conditions pour limiter le nombre d’enregistrements répliqués et assurez-vous que toutes les colonnes requises sont incluses dans l’ensemble de réplications.
Pour obtenir la liste des tables à éviter pour éviter la réplication, reportez-vous à la section Tables exclues dans Réplication de données d'instance.
Analyse des hiérarchies de tables
Consultez Conservation de la hiérarchie des tables dans Réplication de données d'instance.
Analyse des relations entre les tables
Pour chaque table que vous souhaitez répliquer, déterminez si la table possède des champs de référence qui pointent vers d’autres tables. Si vous répliquez une table avec un champ de référence qui pointe vers une autre table, mais que vous n’incluez pas cette table dans votre ensemble de réplications, le champ de référence sera vide dans l’enregistrement sur l’instance du consommateur. La réplication des relations entre les tables préserve l’intégrité des données et garantit que les champs de référence sont renseignés sur le consommateur comme prévu.
Organisation des ensembles de réplication
Dans le cadre de la phase de planification, déterminez comment vous souhaitez organiser vos ensembles de réplication et les tables qu’ils contiennent.
- Créer un ensemble de réplications unique pour chaque table. Cette option nécessite plus d’installation, de configuration et de gestion du temps, mais vous permet d’interrompre la réplication pour une seule table sans impact sur les autres tables.
- La réplication est effectuée en parallèle à l’aide de plusieurs tâches.
- Les mesures de débit sont plus faciles à suivre avec des ensembles de réplication distincts.
- Lorsqu’une erreur se produit, la réplication d’une seule table est affectée au lieu de toutes les tables multiples.
- Créez un ensemble de réplications pour un groupe de tables connexes. Cette option est plus facile à configurer et à gérer, mais la supervision et les problèmes potentiels ont un impact sur toutes les tables du groupe.
- Si vous avez besoin d’informations sur l’état de la réplication, le nom logique que vous utilisez pour cet ensemble de réplications peut être plus facile à trouver et à comprendre que d’utiliser des ensembles de réplications distincts pour chaque table.
- Si vous souhaitez interrompre la réplication, vous pouvez le faire pour l’ensemble du groupe de tables en interrompant la réplication à partir d’un ensemble de réplications.
- Si un problème de réplication se produit sur une table et que la réplication s’arrête, cela arrête la réplication pour toutes les tables de l’ensemble de réplications.
Si vous décidez de regrouper les tables dans un seul ensemble de réplications, essayez de le limiter à cinq tables ou moins. Si vous avez plus de cinq tables à répliquer, utilisez plusieurs ensembles de réplications avec cinq tables ou moins dans chaque ensemble.
Choix des colonnes à répliquer
Pour chaque table que vous souhaitez répliquer, décidez des colonnes à inclure. Évitez d’inclure toutes les colonnes de votre ensemble de réplications par défaut. Au lieu de cela, décidez quelles colonnes sont nécessaires et excluez toutes les colonnes sys_ ou d’autres colonnes qui sont automatiquement mises à jour par les scripts.
Par exemple, si vous incluez une colonne mise à jour automatiquement par le système fréquemment, IDR les données peuvent être répliquées plus souvent que nécessaire. Lorsque le système réplique ces données, cela peut avoir un impact négatif sur l’abonnement de capacité. Vérifiez régulièrement le tableau de bord de la licence IDR et des détails d’utilisation pour surveiller le nombre de messages générés par le créateur.
Préparation des tables cibles sur l’instance de consommateur
Par défaut, IDR utilise le champ de sys_id d’un enregistrement comme valeur de recherche pour maintenir la synchronisation des données entre l’instance producteur et l’instance de consommateur. Si la table cible contient des données existantes ou des enregistrements provenant d’importations de données antérieures, les valeurs sys_id dans le consommateur ne correspondent pas aux sys_ids de l’instance du producteur.
Considérez toujours l’instance du producteur comme la source de la vérité. Pour des résultats de réplication optimaux, suivez ces directives :
- Faites de l’instance de créateur la source de données exclusive de l’instance de consommateur.
- Avant la réplication, assurez-vous que la table cible dans l’instance consommateur est vide. Idéalement, les enregistrements initiaux dans l’instance cible sont créés à partir de données envoyées exclusivement par le producteur via un ensemble de réplications ou un clone.
- Assurez-vous qu’il n’y a pas d’autres importations ou mises à jour de données en cours vers les tables cibles sur l’instance du consommateur après le démarrage de la réplication.
Par exemple, si les utilisateurs de LDAP sont importés dans l’instance de consommateur à l’aide d’une source de données différente, les sys_ids de ces enregistrements ne correspondent pas aux valeurs sys_id de l’instance du producteur. Dans ce scénario, les enregistrements utilisateur existants dans la table cible sur le consommateur ne sont pas mis à jour et des enregistrements en double sont créés.
Dans les situations où cela ne peut être évité, nettoyez les tables sur l’instance du consommateur avant la réplication. Vous devez supprimer les enregistrements de la table cible ou vous assurer que les valeurs sys_id dans Producteur et Consommateur sont identiques.
Vous pouvez également utiliser un champ Fusion personnalisé pour identifier des enregistrements uniques (au lieu de la colonne sys_id par défaut) pour la réplication. Utilisez une colonne Fusion personnalisée lorsque les enregistrements de l’instance de consommateur ont une sys_id différente pour les mêmes enregistrements sur l’instance du créateur. Pour plus d’informations sur l’utilisation d’une fusion personnalisée, reportez-vous à la section Fusion personnalisée.
Examen des règles métier
Vous pouvez utiliser des règles métier pour déclencher des workflows après la réplication, tels que l’envoi d’une notification ou la validation des données répliquées. Examinez toutes les règles métier sur l’instance de consommateur susceptibles d’empêcher l’utilisateur idr.system d’insérer, de mettre à jour ou de supprimer des enregistrements dans la table cible.
Si des défaillances liées aux règles métier se produisent, elles apparaissent dans le sur l’instance du consommateur. Affichez le champ Message d’erreur pour plus de détails sur le script à l’origine de l’échec.
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.
Examen des ACL
Examinez les ACL en place sur la table cible dans l’instance de consommateur pour vous assurer que IDR les données peuvent être répliquées avec succès. Vérifiez que l’utilisateur idr.system dispose des rôles appropriés pour la table cible.
Si des défaillances liées aux ACL se produisent, elles apparaissent dans le sur l’instance du consommateur. Consultez le champ Message d’erreur pour plus de détails sur l’ACL à l’origine de la défaillance.
Examen des politiques de données
Examinez toutes les politiques de données en place sur la table cible dans l’instance de consommateur pour vous assurer que IDR les données peuvent être répliquées avec succès. Vérifiez que les données que vous répliquez respectent la politique de données.
Si des défaillances liées aux politiques de données se produisent, elles apparaissent dans le sur l’instance du consommateur. Affichez le champ Message d’erreur pour plus de détails sur la politique de données à l’origine de l’échec.