Benefits

• Data is automatically replicated to one or more other instances.
• Data can be modified and mapped to any table and table column on other instances. For example, you can modify and map table columns to localize data for different locales.
• Data that is updated on consumer instances can be replicated to the producer instance.

  Data, such as problem requests, can be given on consumer instances to third parties. The third parties can update the problem issue and return it to the consumer instance. The data can then be updated on the producer instance.

• Business rules can trigger post-replication workflows, such as generating notifications or validating the replication.
• Data that is in transit during a crash is recoverable.

How Instance Data Replication works

You use the Instance Data Replication plugin to replicate data updates on one instance, called the producer instance, to one or more other instances, called consumer instances.

By configuring a producer replication set, you can specify the tables and table columns on the producer instance to replicate. When you configure a consumer data set, you can specify the tables and table columns on the consumer instances that receive the producer replication set data.

Next, you activate both producer and consumer replication sets to turn on the IDR functionality. The data that is updated in a producer replication set automatically updates the corresponding data in the consumer replication sets.

Syncing the producer and consumer replication sets requires that you do a one-time download called seeding of all the producer replication set data to the consumer instances. You can initiate seeding requests on a consumer instance while you are activating a consumer replication set. After seeding, your future replications involve data updates only. An audit trails contain a history of those record updates.

By default, the table data on a producer instance goes into the tables of the same name on consumer instances. Transformation is the process of replicating producer data in differently named tables or table columns on consumer instances.

IDR adapters modify data before storing it on consumer instances. Adapters perform string and mathematical operations, such as converting one currency to another, or converting one time zone to another.

Producer and Consumer instance data replication delays

After IDR has been set up on the producer instance, a job (IDRProducerJob) runs on producer instances to detect data updates. When there are updates to replicate, the producer instance sends the updates to consumer instances.

The IDRConsumerJob runs on the consumer instances to detect the data updates from a producer. When IDRConsumerJob finds updates, it updates the data in consumer tables.

It takes some time for the data updates in a producer replication set to appear in consumer replication sets. You can look on the monitoring dashboard to see how long data updates move from a producer replication set to consumer replication sets.

If you have significant data delays, contact ServiceNow Technical Support.

Domain separation

IDR runs in ServiceNow datacenters only. It functions at the data level so IDR does not explicitly support domain separation. Data moves from a producer instance to a consumer instance without regard to which domain the instance is in. However, you can use business rules to convert from one domain to another. For more information, see About Before Query business rules.

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 clone instances.

• Do not use IDR if your use case breaks any of the following IDR limitations:
  • Replication must not take longer than seven days to complete.
  • Initial seeding of the tables must be less than 3 million records per replication set.
  • Producer and consumer instances must be in the same geographic region.

What to do next

Get an overview of setting up IDR.