Comparing replicated data between instances in Instance Data Replication
Summarize
Summary of Comparing replicated data between instances in Instance Data Replication
Instance Data Replication (IDR) enables synchronization of data between a producer instance and one or more consumer instances within ServiceNow. After activating a producer replication set and subscribing at least one consumer, existing records are seeded from the producer to the consumer to initiate synchronization. IDR then maintains ongoing synchronization by replicating new and changed records.
Show less
If discrepancies occur—such as failed inserts on the consumer or mismatched records after replication—ServiceNow customers can use the data comparison feature in IDR to identify missing or mismatched records and reseed them to restore synchronization.
Key Features
- Identify Missing Records: Detect records that are present in the producer but missing in the consumer instance after seeding.
- Identify Mismatched Records: Detect and compare differences in records that exist on both producer and consumer but do not match.
- Reseeding Capability: Reseed identified missing or mismatched records from the producer to the consumer to maintain data consistency.
- Support for Transformed Data: Data comparison supports replication sets with transformations, but mapped fields with differing definitions or those modified by adapters (except Task number adapter) are skipped to avoid inaccurate comparisons.
- Compatibility Considerations: Data comparison supports bidirectional, discrete, and transformed replication sets beginning with the Washington DC release. Compatibility varies depending on the release versions of producer and consumer instances, with limitations noted for older releases.
Compatibility Details
Data comparison is fully supported when both producer and consumer run Washington DC release or later, including all replication set types. Compatibility is limited or unsupported when instances run earlier releases (Utah or Vancouver), especially for bidirectional, discrete, or transformed replication sets.
Limitations
- Journal fields are excluded from comparison due to their potentially large size.
- Records from the Sys Audit [sysaudit] table are excluded from data comparison.
Practical Application for ServiceNow Customers
ServiceNow customers can leverage the IDR data comparison feature to efficiently troubleshoot and correct replication inconsistencies. By identifying missing or mismatched records after initial seeding or during ongoing replication, customers can reseed data to ensure consistent and accurate synchronization across instances. This functionality is critical for maintaining data integrity in environments using multiple ServiceNow instances with replicated data.
Related Tasks and Concepts
- Deploying replication configurations between instances
- Cloning instances with Instance Data Replication
- Monitoring replication status and queues
- Avoiding insert and update errors during replication
- Managing consumer access to replication data
- Resolving data replication errors
Find missing or mismatched records by comparing replication data between instances in Instance Data Replication (IDR).
IDR synchronizes data between a producer instance and one or more consumer instances. After you activate a producer replication set and subscribe at least one consumer, you can send existing records from the producer to the consumer by seeding records. After seeding is finished, IDR maintains data synchronization between the instances by replicating new and changed records from the producer to the consumer.
If an insert fails on the consumer or when producer and consumer records don’t match after replication, you can use the data comparison feature in IDR to find these records and reseed them from the producer to the consumer.
Key benefits
- Identify records missing from the consumer instance after seeding.
- Identify mismatched records and view their differences.
- Keep data synchronized between instances by reseeding records.
Comparing transformed data
- The data comparison can return mixed results if records are added to a table on the producer and then a transformation replicates to a different table on the consumer instance.
- Mapped fields with different field definitions are skipped. For example, if a field on the producer has a different column type or column length than the mapped field on the consumer, the field is skipped.
- All fields that are modified by an adapter are skipped except for modifications made by the Task number adapter. For example, if a string is appended using the Concatenate String adapter, the data comparison can't undo the concatenation and compare the data using the original string, so the field is skipped.
Compatibility
Beginning in the Washington DC release, you can compare replicated data in bidirectional replication sets, discrete replication sets, and replication sets with transformations configured on either the producer or the consumer.
| Data comparison | Producer | Consumer | Supported replication sets |
|---|---|---|---|
| Producer to consumer | Washington DC or later | Utah and earlier | None |
| Producer to consumer | Washington DC or later | Vancouver | Supports unidirectional replication sets, but not the following:
|
| Producer to consumer | Washington DC or later | Washington DC or later | All replication sets |
| Data comparison | Consumer | Producer | Supported replication sets |
|---|---|---|---|
| Consumer to producer | Washington DC or later | Utah and earlier | None |
| Consumer to producer | Washington DC or later | Vancouver | Supports bidirectional replication sets, but not the following:
|
| Consumer to producer | Washington DC or later | Washington DC or later | All replication sets, but not unidirectional replication sets |
Limitations
- Journal fields are excluded from the comparison due to the potential size of their content.
- Sys Audit [sys_audit] table records are excluded from the comparison.