Exploring Instance Data Replication
Summarize
Summarized using AI
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.
Summary of Exploring Instance Data Replication
Instance Data Replication (IDR) enables seamless data synchronization between a producer instance and one or more consumer instances, enhancing data consistency across your organization. With IDR, you can automatically replicate updates, ensuring that changes in one instance are reflected in others in near-real time, even allowing for data recovery during crashes.
Show less
IDR Users
The primary user of IDR is the IDR administrator, who manages which tables and columns are replicated, creates replication sets, and monitors the replication process to ensure data integrity.
IDR Workflow
The IDR workflow involves the following steps:
- The IDR admin creates a producer replication set on the producer instance, specifying which tables and columns to replicate.
- The admin activates this set, allowing data to be available for consumer instances.
- On consumer instances, the admin creates consumer replication sets to receive data and requests approval from the producer instance.
- Upon approval, the consumer replication sets are activated, allowing for automatic updates based on changes made in the producer set.
- Data can optionally be seeded from the producer to consumer instances, and transformations can be configured to accommodate any naming differences in tables and columns.
Key Features
- Continuous Replication: Ensures near-real-time data updates across instances.
- Scheduled Replication: Allows for historical data replication at predefined intervals.
- Bidirectional Replication: Enables two-way data updates between instances.
- Discrete Replication: Ensures that each consumer instance receives updates independently.
- Data Transformation: Allows mapping and modifying data to align with different naming conventions or formats.
- Post-Replication Workflows: Triggers business rules or notifications after data replication.
IDR Limitations
While IDR is powerful, it has specific limitations:
- IDR does not clone instances or replicate metadata tables, large attachments regularly, or continuous changes to CMDB tables.
- Maximum record size is 10 MB; continuous replication can handle around 1 million records per day.
- Data privacy must be considered, as IDR can overwrite existing data and replicate sensitive information.
Next Steps
To further explore IDR, consider reviewing the following:
- Configuring Instance Data Replication
- Replicating data with Instance Data Replication
- Administering Instance Data Replication
- Instance Data Replication reference
Instance Data Replication (IDR) replicates data updates on one instance, called the producer instance, to one or more other instances, called the consumer instances.
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
| 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.
- 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
| 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 .
- 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 in IDR, with only one outbound entry in that set.
Warning:
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: