Préparation pour Réplication de données d'instance
Avant d’installer Réplication de données d'instance (IDR), analysez les tables et les colonnes des instances de créateur et de consommateur pour répliquer les données avec succès.
Choix des tables à répliquer
Avant de créer un ensemble de réplications de producteur, choisissez 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 contiennent des données existantes dans l’instance du 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 à effectuer par la suite.
Évitez de dupliquer les CMDB tables. La réplication des tables CMDB peut entraîner des problèmes de performances ou des conséquences imprévues en raison du nombre d’enregistrements impliqués. Si vous déterminez que les tables CMDB doivent être répliquées, utilisez des conditions pour limiter le nombre d’enregistrements répliqués et vous assurer que toutes les colonnes requises sont incluses dans le jeu de réplication.
Pour obtenir la liste des tables que vous évitez de répliquer, reportez-vous à la section Tables exclues dans Réplication de données d'instance.
Analyser les hiérarchies de tables
Pour chaque table que vous souhaitez répliquer, déterminez si la table est une table parente ou enfant. Si la table appartient à une hiérarchie parent-enfant, décidez si vous souhaitez conserver la hiérarchie et quelle stratégie vous souhaitez utiliser pour déplacer la hiérarchie du producteur vers le consommateur. La réplication des tables parent et enfant préserve l’intégrité des données et garantit que les champs de référence sont renseignés sur le consommateur comme vous pouvez vous y attendre. Consultez Conservation de la hiérarchie des tables dans Réplication de données d'instance.
Analyser les relations entre les tables
Pour chaque table que vous souhaitez répliquer, déterminez si la table dispose de 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 jeu de réplications, le champ de référence sera vide dans l’enregistrement sur l’instance de consommateur. La réplication des relations de table préserve l’intégrité des données et garantit que les champs de référence sont renseignés sur le consommateur comme vous pouvez vous y attendre.
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 de mettre en pause la réplication pour une seule table sans impact sur les autres tables.
- Créez un ensemble de réplications pour un groupe de tables connexes. Cette option est plus facile à configurer et à gérer, mais la surveillance et les problèmes potentiels ont un impact sur toutes les tables du groupe. Par exemple :
- Si vous avez besoin de trouver des 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 si vous utilisez des ensembles de réplication distincts pour chaque table.
- Si vous souhaitez mettre en pause 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 du jeu de réplication.
Si vous décidez de regrouper des tables dans un ensemble de réplication unique, essayez de le limiter à cinq tables ou moins. Si vous avez plus de cinq tables à répliquer, utilisez plusieurs ensembles de réplication avec cinq tables ou moins dans chaque ensemble.
Choix des colonnes à répliquer
Pour chaque table que vous souhaitez répliquer, choisissez les 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 et fréquemment par le système, 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 des détails de licence et d’utilisation IDR 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 sys_id d’un enregistrement comme valeur de recherche pour maintenir la synchronisation des données entre l’instance de créateur et de consommateur. Si la table cible contient des données existantes ou des enregistrements provenant d’importations de données antérieures, les valeurs de sys_id dans le consommateur ne correspondent pas aux sys_ids de l’instance de producteur.
Considérez toujours l’instance du producteur comme la source de la vérité. Pour des résultats de réplication optimaux, suivez les directives suivantes :
- Faites de l’instance de créateur la source de données exclusive pour l’instance de consommateur.
- Avant la réplication, assurez-vous que la table cible de l’instance de consommateur est vide. Dans l’idéal, les enregistrements initiaux de l’instance cible sont créés à partir de données envoyées exclusivement par le producteur via un jeu de réplication ou un clone.
- Assurez-vous qu’il n’y a pas d’autres importations de données ou mises à jour 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 de sys_id de l’instance de producteur. Dans ce scénario, les enregistrements d’utilisateur existants dans la table cible du consommateur ne sont pas mis à jour et des enregistrements en double sont créés.
Dans les cas où cela ne peut être évité, nettoyez les tables sur l’instance du consommateur avant la réplication. Vous devez supprimer les enregistrements dans la table cible ou vous assurer que les valeurs de sys_id dans les champs producteur et consommateur sont identiques.
Vous pouvez également utiliser un champ de fusion personnalisé pour identifier les 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 de l’instance de producteur. Pour plus d’informations sur l’utilisation d’une fusion personnalisée, reportez-vous à la section Fusionner des colonnes dans Réplication de données d'instance.
Examiner les règles métier
Vous pouvez utiliser des règles métier pour déclencher des workflows après la réplication, comme 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 qui peuvent 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 de 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 vers 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 de producteur.
Examen des ACL
Passez en revue les ACL en place sur la table cible de l’instance de consommateur pour vous assurer que vous IDR pouvez répliquer les donné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 de consommateur. Affichez le champ Message d’erreur pour plus de détails sur l’ACL à l’origine de la défaillance.
Examiner les 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 IDR données peuvent être correctement répliquées. Vérifiez que les données que vous répliquez sont conformes à 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 de consommateur. Affichez le champ Message d’erreur pour plus de détails sur la politique de données à l’origine de l’échec.