Explorer Réplication de données d'instance

Réplication de données d'instance (Analyse de l'intégrité des journaux) fournit une réplication un-à-plusieurs, ce qui permet à une instance de propager des données entre différents départements et unités business afin de maintenir la synchronisation des données.

Analyse de l'intégrité des journaux Prend également en charge la réplication bidirectionnelle. La réplication bidirectionnelle vous permet de copier les données d’une instance de producteur vers une instance de consommateur, puis d’une instance de consommateur vers l’instance de producteur.

Avantages

• Les données sont automatiquement répliquées vers une ou plusieurs autres instances.
• Les données peuvent être modifiées et mappées à n’importe quelle table et colonne de table sur d’autres instances. Par exemple, vous pouvez modifier et mapper des colonnes de table pour localiser des données pour différents paramètres régionaux.
• Les données mises à jour sur les instances de consommateur peuvent être répliquées sur l’instance du producteur.

  Les données, telles que les demandes de problème, peuvent être copiées vers des instances de consommateur pour que des tiers puissent les utiliser. Le tiers peut mettre à jour le problème sur l’instance du consommateur. Les données peuvent ensuite être mises à jour sur l’instance du producteur.

• Les règles métier peuvent déclencher des workflows post-réplication, tels que la génération de notifications ou la validation de la réplication.
• Les données en transit lors d’un incident sont récupérables.

Mode de fonctionnement de Réplication de données d'instance

Vous utilisez le module d’extension (com.glide.idr) pour répliquer les Réplication de données d'instance mises à jour de données sur une instance, appelée instance productrice, vers une ou plusieurs autres instances, appelées instances consommateur.

En configurant un ensemble de réplications du producteur, vous pouvez spécifier les tables et les colonnes de table sur l’instance du producteur à répliquer. Lorsque vous configurez un ensemble de données du consommateur, vous pouvez spécifier les tables et les colonnes de table sur les instances du consommateur qui reçoivent les données de l’ensemble de réplications du producteur.

Ensuite, vous activez les ensembles de réplication du producteur et du consommateur pour activer la Analyse de l'intégrité des journaux fonctionnalité. Les données mises à jour dans un ensemble de réplications du créateur mettent automatiquement à jour les données correspondantes dans les ensembles de réplications du consommateur.

La synchronisation des ensembles de réplications du producteur et du consommateur nécessite un téléchargement unique (appelé amorçage) de toutes les données de l’ensemble de réplications du producteur vers les instances du consommateur.

Vous pouvez lancer des demandes d’amorçage sur une instance de consommateur lorsque vous activez un ensemble de réplications du consommateur. À partir de la Rome mise en production, vous pouvez utiliser une fonctionnalité de critère de filtre (appelée amorçage partiel) pour limiter le nombre d’enregistrements qui sont amorcés. Utilisez l’amorçage partiel pour diviser les tâches volumineuses en tâches plus petites lorsque vous avez un grand nombre d’enregistrements à dupliquer.

Après l’amorçage, la réplication implique uniquement la mise à jour des données. Une piste d’audit contient un historique de ces mises à jour d’enregistrement.

Par défaut, les données de table d’une instance de créateur sont transmises aux tables du même nom sur les instances de consommateur. La transformation est le processus de réplication des données du producteur dans des tables ou des colonnes de table portant un nom différent sur les instances de consommateur.

Analyse de l'intégrité des journaux Les adaptateurs modifient les données avant de les stocker sur des instances de consommateur. Les adaptateurs effectuent des opérations mathématiques et de chaîne, telles que la conversion d’une devise en une autre ou la conversion d’un fuseau horaire en un autre.

Figure 1. Vue d'ensemble de Analyse de l'intégrité des journaux

Avertissement :

Analyse de l'intégrité des journaux Remplace les données sur les instances et peut répliquer les données sensibles. Évitez la perte et l’exposition potentielles des données en testant votre Analyse de l'intégrité des journaux implémentation dans un environnement de pré-production. Pour plus d’informations, consultez la section Confidentialité des données dans IDR .

Ensembles de réplications hérités et V2

Analyse de l'intégrité des journaux prend en charge les ensembles de réplication hérités et V2. À compter de la Washington DC mise en production, vous ne pouvez plus créer d’ensembles de réplication hérités.

• Les ensembles de réplication hérités utilisent une ServiceNow implémentation de transport et de remise de message Kafka créée avant la Utah publication. Tous les ensembles de réplications créés avant la Utah publication sont considérés comme des ensembles de réplication hérités.
• Les ensembles de réplication V2 utilisent le pour le transport et la remise de messages ServiceNow Service de messagerie Hermes Kafka. Il s’agit Service de messagerie Hermes d’une Now Platform fonctionnalité qui permet Analyse de l'intégrité des journaux de répliquer les données plus rapidement et à grande échelle.

Les ensembles de réplications du producteur hérités ne sont compatibles qu’avec les ensembles de réplications du consommateur hérités. De même, les ensembles de réplication du producteur V2 ne sont compatibles qu’avec les ensembles de réplication du consommateur V2.

Vous pouvez créer de nouveaux ensembles de réplication V2 ou mettre à niveau les ensembles de réplication hérités existants vers V2. Consultez Mise à niveau des ensembles de réplication hérités vers V2 dans Réplication de données d'instance.

Analyse de l'intégrité des journaux et les mises à niveau d’instance

La mise à niveau de votre instance avec Analyse de l'intégrité des journaux activé est un processus transparent.

• Analyse de l'intégrité des journaux ne consomme pas et ne produit pas de messages lors d’une mise à niveau d’instance. Analyse de l'intégrité des journaux Les tâches sont automatiquement arrêtées lorsque la mise à niveau commence.
• Le data_replication_queue suit l’horodatage du dernier message envoyé. Cela garantit la reprise de la réplication à partir de la dernière modification apportée avant la mise à niveau.
• Tout amorçage en cours avant la mise à niveau sera automatiquement mis en pause au démarrage de la mise à niveau et reprendra une fois la mise à niveau terminée. Pour vous assurer que l’amorçage se termine sans interruption, évitez de lancer une demande d’amorçage avant une mise à niveau.
• Les demandes d’amorçage ne peuvent pas être lancées pendant une mise à niveau d’instance.
• La réplication reprend immédiatement après la mise à niveau. Il n’est pas nécessaire d’effectuer des ajustements pour Analyse de l'intégrité des journaux que la réplication d’enregistrement se poursuive.

Analyse de l'intégrité des journaux Limites et quand ne pas utiliser Analyse de l'intégrité des journaux

• Ne pas utiliser Analyse de l'intégrité des journaux pour cloner des instances.

  Analyse de l'intégrité des journaux ne réplique pas les tables de métadonnées, les tables de métadonnées enfants et la plupart des tables utilisateur et système. Analyse de l'intégrité des journaux est conçu pour répliquer des données, pas pour cloner des instances. Par exemple, la table Fichier d’application [sys_metadata] et les tables qui étendent [sys_metadata] (y compris les tables Règles métier [sys_script], Catalogue [sc_catalog] et Workflow [wf_workflow]) sont exclues et ne peuvent pas être répliquées. Pour en savoir plus sur le clonage, reportez-vous à la section System clone.

• Évitez de l’utiliser Analyse de l'intégrité des journaux pour reproduire régulièrement une série de pièces jointes volumineuses. Si vous devez inclure régulièrement des pièces jointes de plus de 10 Mo, surveillez Analyse de l'intégrité des journaux pour vous assurer que le temps de latence ne dépasse pas les attentes.
• Évitez de répliquer des CMDB tables. Si vous déterminez que les tables doivent être répliquées, vous devez utiliser 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.
• Vous ne pouvez pas répliquer les champs Edge Encrypted, Column Level Encryption (CLE) et Password (2-Way Encrypted).
• Limitations de la réplication des enregistrements mis à jour :
  • La taille maximale de l’enregistrement est de 32 Mo.
  • Analyse de l'intégrité des journaux Prend en charge la réplication d’environ 1 million d’enregistrements par jour.
• Limitations pour les enregistrements d’amorçage :
  • L’amorçage de réplication ne doit pas prendre plus de sept jours.
  • L’amorçage initial des tables ne doit pas dépasser 3 millions d’enregistrements par ensemble de réplications.
  Remarque :

  Pour surmonter ces limitations, réduisez le nombre de tables dans la demande d’amorçage, réduisez la taille des enregistrements ou utilisez l’amorçage partiel.