Instance Data Replication (IDR ) copies data
updates from one instance to one or more other instances. IDR enables you to maintain consistent data across
different organizations in your company.
IDR provides a one-to-many replication, which enables one
instance to propagate data across different departments and business units to keep data in
sync. With IDR , you can also modify data during
replication. For example, you could localize the data during replication.
Watch this video to learn how to set up IDR between
multiple instances on the Now Platform .VIDEO
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.
Figure 1. IDR overview
Warning: IDR overwrites data on instances and
can replicate sensitive data. Given the potential for data loss and data exposure, test your
IDR implementation in a pre-production
environment.
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.
