Explorer Réplication de données d'instance
Réplication de données d'instance (IDR) réplique les mises à jour de données sur une instance, appelée instance de producteur, vers une ou plusieurs autres instances, appelées instances de consommateur.
Vue d'ensemble de IDR
Maintenez des données cohérentes entre les différentes instances à l’aide de IDR.
- Répliquer automatiquement les données vers une ou plusieurs autres instances.
- Synchronisez les données entre différentes organisations de votre entreprise, voire entre différentes entreprises disposant d’instances distinctes.
- Les données en transit lors d’un crash sont récupérables.
IDR utilisateurs
| Utilisateur | Description |
|---|---|
| IDR administrateur | L’administrateur IDR détermine les tables et colonnes à répliquer et analyse les hiérarchies et les relations entre les tables. L’administrateur IDR crée des ensembles de réplication du producteur et du consommateur et surveille la réplication en cours. |
Workflow IDR
Cette image montre comment IDR réplique les données de plusieurs tables sur une instance de créateur vers plusieurs instances de consommateur.
- Sur l’instance du producteur, l’administrateur IDR spécifie les tables et les colonnes de table à répliquer en créant un ensemble de réplications du producteur.
- L’administrateur IDR active l’ensemble de réplications du producteur, ce qui rend les données du producteur disponibles pour la réplication pour les consommateurs.
- L’administrateur IDR crée des ensembles de réplications de consommateur sur une ou plusieurs instances de consommateur pour recevoir les données de l’ensemble de réplications du producteur.
- Sur chaque instance de consommateur, l’administrateur IDR demande l’approbation de l’instance du créateur.
- Sur l’instance du créateur, l’administrateur IDR approuve ou refuse les demandes de chaque instance de consommateur.
- Sur chaque instance de consommateur approuvée, l’administrateur IDR active l’ensemble de réplication du consommateur. Une fois la réplication du consommateur activée, les données mises à jour dans un ensemble de réplications du producteur mettent automatiquement à jour les données correspondantes dans les ensembles de réplications du consommateur.
- Sur chaque instance de consommateur, l’administrateur IDR peut éventuellement répliquer des données existantes à partir de l’instance de producteur en amorçant les données sur les instances de consommateur.
- Sur l’instance de producteur ou de consommateur, l’administrateur IDR peut éventuellement répliquer des données vers des tables ou des colonnes de table qui ont des noms différents sur l’instance de consommateur en configurant une transformation dans l’ensemble de réplications.
- Sur l’instance de producteur ou de consommateur, l’administrateur IDR peut modifier les données du producteur avant de les répliquer vers un consommateur en configurant un adaptateur dans le jeu de réplication.
IDR avantages
| Avantage | Fonctionnalité | Utilisateurs |
|---|---|---|
| Répliquez en continu les insertions et les mises à jour d’une instance de producteur vers une ou plusieurs instances de consommateur en temps quasi réel, garantissant un délai minimal. | Réplication continue | Administrateur |
| Planifiez la réplication des insertions et des mises à jour historiques d’une instance de créateur vers une ou plusieurs instances de consommateur à des intervalles prédéfinis. | Réplication planifiée | Administrateur |
| Répliquez en continu les insertions et les mises à jour d’une instance de créateur vers une instance de consommateur en temps quasi réel, les modifications de chaque côté étant répliquées de part et d’autre. | Réplication bidirectionnelle | Administrateur |
| Répliquez en continu les insertions et les mises à jour d’une instance de producteur vers des instances de consommateur spécifiques et distinguées en temps quasi réel, en veillant à ce que chaque instance de consommateur reçoive des mises à jour indépendamment. | Réplication discrète | Administrateur |
| Mappez les données du producteur à des tables et des colonnes de table nommées différemment sur les instances des consommateurs. Par exemple, vous pouvez modifier et mapper des colonnes de table pour localiser des données pour différents paramètres régionaux. | Transformer les données de réplication | Administrateur |
| Modifiez les données du producteur avant de les répliquer vers une instance de consommateur à l’aide d’un adaptateur. Par exemple, vous pouvez configurer des adaptateurs qui 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. | Transformer les données de réplication | Administrateur |
| Déclenchez des workflows post-réplication tels que la génération de notifications ou la validation de la réplication à l’aide de règles métier. | Déclenchement d’un workflow après la réplication | Administrateur |
IDR limitations et quand ne pas utiliser IDR
- Ne l’utilisez IDR pas 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 utilisateur et système. 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 plus d’informations sur le clonage, reportez-vous à la section .
- IDR Évitez de 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-les IDR pour vous assurer que le temps de latence ne dépasse pas les attentes.
- Évitez la réplication continue des CMDB tables. La réplication des CMDB données au fur et à mesure des changements peut créer 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 utilisez 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.
- Vous ne pouvez pas répliquer les champs chiffrés Edge Chiffrement de champet Mot de passe (chiffré dans les deux sens).
- Limitations de réplication supplémentaires :
- La taille d’enregistrement maximale est de 32 Mo.
- La réplication continue prend en charge jusqu’à environ 1 million d’enregistrements par jour.
- L’ensemencement ne doit pas prendre plus de sept jours.
Avertissement :
IDR Remplace les données sur les instances et peut répliquer les données sensibles. Évitez la perte et l’exposition potentielles de données en testant votre IDR implémentation dans un environnement de pré-production. Voir Confidentialité des données dans IDR pour plus d’informations.
Ce qu'il faut explorer ensuite
Pour en savoir plus sur la configuration et l'utilisation de IDR, consultez :