Préparation pour Réplication de données d'instance
Avant de configurer Réplication de données d'instance (Analyse de l'intégrité des journaux), analysez les tables et les colonnes dans les instances de producteur et de consommateur pour réussir la réplication des données.
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 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 reproduire ces tables, vous aurez peut-être du travail supplémentaire par la suite pour nettoyer ces tables.
Évitez de répliquer des CMDB tables. La réplication des tables CMDB peut créer des problèmes de performances ou des conséquences imprévues avec la réplication en raison du nombre d’enregistrements concerné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 assurez-vous que toutes les colonnes requises sont incluses dans le jeu de réplication.
Pour obtenir la liste des tables que vous devez éviter de répliquer, 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 comporte 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 jeu de réplication, 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é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 affecter 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 de trouver des informations sur l’état de réplication, le nom logique que vous utilisez pour cet ensemble de réplication peut être plus facile à trouver et à comprendre qu’avec 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 mettant en pause 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 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éplication 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 chaque colonne dans 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 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, Analyse de l'intégrité des journaux 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 Licence IDR et détails de l’utilisation pour surveiller le nombre de messages générés par le producteur.
Préparation des tables cibles sur l’instance de consommateur
Par défaut, Analyse de l'intégrité des journaux utilise le champ sys_id d’un enregistrement comme valeur de recherche pour maintenir la synchronisation des données entre les instances producteur et 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 du 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 les instructions suivantes :
- Faites de l’instance de producteur la source de données exclusive pour l’instance de consommateur.
- Avant la réplication, assurez-vous que la table cible dans l’instance de consommateur est vide. Idéalement, les enregistrements initiaux de 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 de données en cours ou de mises à jour 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 autre source de données, les sys_ids de ces enregistrements ne correspondent pas aux valeurs sys_id de l’instance du producteur. Dans ce scénario, les enregistrements d’utilisateurs existants dans la table cible sur le consommateur ne sont pas mis à jour et des enregistrements en double sont créés.
Si 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 de sys_id dans producteur et consommateur sont identiques.
Vous pouvez également utiliser un champ de fusion personnalisé pour identifier les enregistrements uniques (au lieu de la colonne de sys_id par défaut) pour la réplication. Utilisez une colonne Fusion personnalisée lorsque les enregistrements de l’instance de consommateur ont un sys_id différent pour les mêmes enregistrements sur l’instance du 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.
Examen des 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 consommateur qui pourraient 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 vers une instance du 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 producteur.
Examen des ACL
Vérifiez les ACL en place sur la table cible dans l’instance de consommateur pour vous assurer que les Analyse de l'intégrité des journaux 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 fichier sur l’instance du consommateur. Affichez 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 qu’elles Analyse de l'intégrité des journaux peuvent répliquer les données avec succès. Confirmez 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 du consommateur. Consultez le champ Message d’erreur pour plus de détails sur la politique de données à l’origine de l’échec.