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 correctement les données.
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 de régions distinctes.
Choix des tables à répliquer
Avant de créer un ensemble de réplications du producteur, décidez des tables à répliquer. Évitez de répliquer les tables système (tables comportant 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 devrez peut-être effectuer 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 entraîner 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 d’utiliser 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 à ne pas répliquer, reportez-vous à la section Tables exclues dans Réplication de données d'instance.
Analyse des hiérarchies de tables
Consultez Préservation 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 est 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éplications
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éez 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 réplication, le nom logique que vous utilisez pour cet ensemble de réplications peut être plus facile à trouver et à comprendre que l’utilisation d’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, la réplication s’arrête pour toutes les tables du jeu de réplication.
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. Décidez plutôt quelles colonnes sont nécessaires et excluez toutes les colonnes sys_ ou autres colonnes qui sont mises à jour automatiquement 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é. Consultez régulièrement le tableau de bord IDR License and Usage Details pour surveiller le nombre de messages générés par le créateur.
Préparation des tables cibles sur l’instance consommateur
Par défaut, utilise IDR 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 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 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 :
- Faire 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 de l’instance de 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 dans 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 de créateur. Pour plus d’informations sur l’utilisation d’une fusion personnalisée, reportez-vous à la section Coalescence 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 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 table sur l’instance 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 sur l’instance du créateur.
Examen des ACL
Passez en revue les ACL en place sur la table cible de l’instance du 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 table sur l’instance consommateur. Consultez le champ Message d’erreur pour plus d’informations 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 du consommateur pour vous assurer que les données peuvent être répliquées IDR 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 table sur l’instance consommateur. Consultez le champ Message d’erreur pour plus de détails sur la politique de données à l’origine de la défaillance.