Explorer Réplication de données d'instance

Réplication de données d'instance (IDR) 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.

IDR prend également en charge la réplication bidirectionnelle. La réplication bidirectionnelle vous permet de copier des données d’une instance de producteur vers une instance de consommateur, et d’une instance de consommateur vers l’instance de producteur.

Avantages

• Les données sont automatiquement répliquées sur 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 vers l’instance du producteur.

  Les données, telles que les demandes de problème, peuvent être copiées dans les instances de consommateur afin 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’une panne sont récupérables.

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

Le module d’extension (com.glide.idr) vous permet de répliquer les Réplication de données d'instance mises à jour de données d’une instance, appelée l’instance de producteur, vers une ou plusieurs autres instances, appelées les instances de consommateur.

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

Ensuite, activez les ensembles de réplication du producteur et du consommateur pour activer la IDR fonctionnalité. Les données mises à jour dans un ensemble de réplications du créateur mettent automatiquement à jour les données correspondantes dans les jeux 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 version, vous pouvez utiliser une fonctionnalité de critère de filtre (appelée amorçage partiel) pour limiter le nombre d’enregistrements amorcés. Utilisez l’amorçage partiel pour diviser des 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 des mises à 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 sur une instance de producteur sont transférées dans les tables du même nom sur les instances de consommateur. La transformation consiste à répliquer les données du producteur dans des tables ou des colonnes de table portant un nom différent dans les instances de consommateur.

IDR Les adaptateurs modifient les données avant de les stocker sur des instances de consommateur. Les adaptateurs exécutent des opérations de chaîne et mathématiques, 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 IDR

Avertissement :

IDR remplace les données sur les instances et peut répliquer des données sensibles. Évitez les pertes et l’exposition potentielles des données en testant votre IDR implémentation dans un environnement de pré-production. Consultez la section Confidentialité des données dans IDR pour plus d’informations.

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

IDR prend en charge les ensembles de réplication hérités et V2. À compter de la version, vous ne pouvez plus créer d’ensembles Washington DC de réplication hérités.

• Les ensembles de réplication hérités utilisent une implémentation de transport et de ServiceNow remise de messages Kafka créée avant la Utah version. Tous les ensembles de réplications créés avant la Utah version sont considérés comme des ensembles de réplications hérités.
• Les ensembles de réplication V2 utilisent la méthode pour le transport et la remise des ServiceNow Service de messagerie Hermes messages Kafka. Il Service de messagerie Hermes s’agit d’une Now Platform aptitude qui permet IDR 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éplications de producteurs V2 ne sont compatibles qu’avec les ensembles de réplications de consommateurs V2.

Vous pouvez créer de nouveaux ensembles de réplications V2 ou mettre à niveau des ensembles de réplications 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.

IDR Limites et quand ne pas l’utiliser IDR

• Ne pas utiliser IDR pour cloner des instances.

  IDR ne réplique pas les tables de métadonnées, les tables de métadonnées enfants et la plupart des tables système et utilisateur. IDR est conçu pour répliquer des données, et non 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 IDR 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 IDR pour vous assurer que le temps de latence ne dépasse pas les attentes.
• Évitez de dupliquer les 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).
• Limites de la réplication des enregistrements mis à jour :
  • La taille maximale de l’enregistrement est de 32 Mo.
  • IDR prend en charge la réplication d’environ 1 million d’enregistrements par jour.
• Limites pour les enregistrements d’amorçage :
  • L’amorçage de la 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.