Comparing replicated data between instances in Instance Data Replication

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 2 minutes to read
    • 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 Comparing Replicated Data Between Instances in Instance Data Replication

    The Instance Data Replication (IDR) feature allows you to compare replicated data between instances to identify missing or mismatched records. After activating a producer replication set and subscribing consumer instances, IDR synchronizes data by seeding existing records and maintaining synchronization for new and changed records. If discrepancies arise, the data comparison tool can help locate issues and reseed records as needed.

    Show full answer Show less

    Key Features

    • Identify missing records from the consumer instance after data seeding.
    • Detect mismatched records and view differences to facilitate resolution.
    • Maintain data synchronization by reseeding records when discrepancies are found.
    • Supports comparison in bidirectional and discrete replication sets, along with transformations.
    • Excludes journal fields, attachments, and sys audit records to streamline comparisons.

    Key Outcomes

    By utilizing the data comparison feature, you can ensure accurate data synchronization between your ServiceNow instances, effectively managing data integrity. This capability is crucial for maintaining operational consistency across environments, especially when dealing with multiple instances or family releases. Customers can efficiently find and resolve data issues, leading to improved data quality and reliability in their applications.

    You can 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

    When comparing transformed data, note the following details:
    • 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.

    When comparing data on different family releases, note the following compatibility options.
    Table 1. Producer to consumer compatibility
    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:
    • bidirectional replication sets
    • discrete replication sets
    • replication sets configured with transformations
    Producer to consumer Washington DC or later Washington DC or later All replication sets
    Table 2. Consumer to producer compatibility
    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:
    • unidirectional replication sets
    • discrete replication sets
    • replication sets configured with transformations
    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.
    • Attachments are not included in data comparisons.
    • Sys Audit [sys_audit] table records are excluded from the comparison.