Explore

IDR overview

Maintain consistent data across different instances using IDR.

Automatically replicate data to one or more other instances.
Synchronize data between different organizations in your company or even between different companies with separate instances.
Data that is in transit during a crash is recoverable.

IDR users

Tableau 1. Users
User	Description
IDR admin	The IDR admin determines which tables and columns to replicate and analyzes table hierarchies and relationships. The IDR admin creates producer and consumer replication sets and monitors ongoing replication.

IDR workflow

This image shows how IDR replicates data from multiple tables on a producer instance to multiple consumer instances.

Data replicates from a producer instance to one or more consumer instances. — Figure 1. Replication overview

On the producer instance, the IDR admin specifies the tables and table columns to replicate by creating a producer replication set.
The IDR admin activates the producer replication set, which makes the producer data available for replication to consumers.
The IDR admin creates consumer replication sets on one or more consumer instances to receive the producer replication set data.
On each consumer instance, the IDR admin requests approval from the producer instance.
On the producer instance, the IDR admin approves or denies the requests from each consumer instance.
On each approved consumer instance, the IDR admin activates the consumer replication set. After the consumer replication is activated, data that is updated in a producer replication set automatically updates the corresponding data in the consumer replication sets.
On each consumer instance, the IDR admin can optionally replicate existing data from the producer instance by seeding data to the consumer instances.
On either the producer or consumer instance, the IDR admin can optionally replicate data to tables or table columns that have different names on the consumer instance by configuring a transformation in the replication set.
On either the producer or consumer instance, the IDR admin can optionally modify producer data before replicating it to a consumer by configuring an adapter in the replication set.

IDR benefits

Tableau 2. benefits
Benefit	Feature	Users
Continuously replicate inserts and updates from a producer instance to one or more consumer instances in near-real time, ensuring minimal delay.	Continuous replication	Administrator
Schedule replication of historical inserts and updates from a producer instance to one or more consumer instances at predefined intervals.	Scheduled replication	Administrator
Continuously replicate inserts and updates from a producer instance to a consumer instance in near-real time, with changes on either side replicated back to the other.	Bidirectional replication	Administrator
Continuously replicate inserts and updates from a producer instance to specific, distinguished consumer instances in near-real time, ensuring each consumer instance receives updates independently.	Discrete replication	Administrator
Map producer data to tables and table columns that are named differently on consumer instances. For example, you can modify and map table columns to localize data for different locales.	Transform replication data	Administrator
Modify producer data before replicating it to a consumer instance using an adapter. For example, you can configure adapters that perform string and mathematical operations, such as converting one currency to another, or converting one time zone to another.	Transform replication data	Administrator
Trigger post-replication workflows such as generating notifications or validating replication using business rules.	Triggering workflows after replication	Administrator

IDR limitations and when not to use IDR

Do not use IDR to clone instances.
IDR does not replicate metadata tables, child metadata tables, and most user and system tables. IDR is designed to replicate data, not to clone instances. For example, the Application File [sys_metadata] table and tables that extend [sys_metadata] (including the Business Rules [sys_script], Catalog [sc_catalog], and Workflow [wf_workflow] tables) are excluded and can't be replicated. For details on cloning, see Instance Clone.
Avoid using IDR to replicate a series of large attachments on a regular basis. If you need to include attachments that are larger than 10 MB regularly, monitor IDR to ensure that the lag time doesn't exceed expectations.
Avoid continuous replication of CMDB tables. Replicating CMDB data as changes occur can create performance issues or unforeseen consequences with replication due to the number of records involved. If you must replicate CMDB tables, consider scheduling replication or use conditions to constrain the count of replicated records and ensure all required columns are included in the replication set.
You cannot replicate Edge Encrypted, Field Encryption, and Password (2-Way Encrypted) fields.
IDR does not synchronize data archiving between instances. For example, archiving records or restoring archive records on a producer instance doesn't affect archived records on the consumer instance (and vice versa). You must create and manage archive rules for each instance independently.
Additional replication limitations:
- Maximum record size is 10 MB.
- Continuous replication supports up to approximately 1 million records per day.
- Seeding must not take longer than seven days to complete.
- You can only create one scheduled replication set, with only one outbound entry in that set.

Avertissement :

IDR overwrites data on instances and can replicate sensitive data. Avoid potential data loss and data exposure, by testing your IDR implementation in a pre-production environment. See data privacy in IDR for more information.

What to explore next

To learn more about configuring and using IDR, see: