Bidirectional replication

  • Release version: Yokohama
  • Updated January 30, 2025
  • 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 Bidirectional replication

    Bidirectional replication in Instance Data Replication (IDR) allows data to flow both ways between a producer instance and a consumer instance. It ensures that inserts and changes to records on either instance are synchronized, keeping tables identical across both instances. This is useful for scenarios such as synchronizing incident records between two ServiceNow instances.

    Show full answer Show less

    To enable bidirectional data flow, the system creates a producer replication set on the consumer instance and a consumer replication set on the producer instance. Replication sets created for reverse direction have a suffix with a randomly generated number followed by "-reverse" and are read-only.

    Key Features

    • Two-way synchronization: Changes in either instance replicate to the other, maintaining consistent data.
    • Automatic creation of reverse replication sets: These sets manage replication in the opposite direction and are read-only.
    • Verification of replication status: Customers can verify producer and consumer roles by running XML status queries on each instance.

    Limitations and Recommendations

    • No auto-conflict resolution: If the same record is modified simultaneously on both instances, the latest update wins, potentially causing data inconsistencies.
    • Adapter support: Only the Number adapter is supported; other adapters are not compatible with bidirectional replication.
    • Business rule updates on consumer: Updates triggered by business rules on the consumer instance after record insertion are not replicated back to the producer.
    • Use cases to avoid bidirectional replication:
      • When using adapters to filter data, it is recommended to use two separate one-way replication sets rather than bidirectional replication.
      • For initial data seeding between instances, use two one-way replication sets instead of bidirectional replication.

    Considerations

    Bidirectional replication helps keep data synchronized but may lead to merge conflicts due to the lack of conflict resolution. Customers should carefully evaluate their use cases and data synchronization needs before implementing bidirectional replication. For detailed implications related to data privacy and transfer, consulting ServiceNow documentation on data privacy in IDR is advised.

    Bidirectional replication in Instance Data Replication (IDR) enables data to flow from a producer instance to a consumer instance and accept data from a consumer instance to flow back to the producer instance.

    All inserts and changes to records on either instance are sent to the other instance to keep the tables identical on both instances. For example, you can enable bidirectional replication for the Incidents table to keep incident records synchronized between two instances.

    To make data flow bi-directionally, the system creates a producer replication set on the consumer instance and a consumer replication set on the producer instance.

    Figure 1. Bi-directional replication
    Consumer and producer replication sets are automatically generated to create bi-directional replication.

    If you look at the replication sets on the original producer instance, you see the replication set name and the automatically generated consumer instance. It has the same name appended with the suffix, -<long-number>-reverse, where <long-number> is a randomly generated number. For example, if Test is the producer replication set name, Test-2034802-reverse might be the name of the consumer replication set that is automatically created on the same instance. On the original consumer instance, you see the same names. Replication sets with the reverse suffix are read-only.

    You can verify a consumer on a producer instance and a producer on a consumer instance by running https://<producer-instance-name>/xmlstats.do?include=idr and https://<consumer-instance-name>/xmlstats.do?include=idr on the producer and consumer instances. In the following image, the original producer instance is on the left and the original consumer instance is on the right.

    Bidirectional replication seen using xmlstats

    Bidirectional replication has the following limitations:
    • Auto-conflict resolution is unsupported.
    • Merge conflicts happen if producer and consumer instances modify the same record at the same time.

      The most recent update wins, which means that the data on the consumer and producer tables might be different.

    • Bidirectional replication supports the Number adapter but none of the other adapters.
    • Bidirectional replication keeps data in sync between producer and consumer instances. However, in some scenarios, avoid using bidirectional replication and use one-way replication instead.
      • If you plan to use adapters to differentiate data replicated between two instances, use two one-way replication sets to replicate data back and forth instead of using bidirectional sets.
      • If you need to seed data from one instance to another and vice versa, use two one-way replication sets.
    • With bidirectional replication, records created on the producer instance are replicated to a consumer instance and vice versa. When the record is inserted on the consumer instance and it triggers a business rule that updates the record, that update is not replicated back to the producer instance.

    If you must understand the implications of bi-direction and data transfer between instances, see data privacy in IDR for more information.