Bidirectional replication for 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 Bidirectional replication for Instance Data Replication

    Bidirectional replication in Instance Data Replication (IDR) allows data to flow seamlessly between a producer instance and a consumer instance, ensuring that all records are synchronized. Changes made to records on either instance will be sent to the other, maintaining identical tables. For instance, enabling bidirectional replication for the Incidents table will keep incident records consistent across two instances.

    Show full answer Show less

    Key Features

    • The system creates a producer replication set on the consumer instance and a consumer replication set on the producer instance.
    • Replication set names on the producer instance will have a corresponding consumer instance name with a suffix indicating the reverse direction.
    • Read-only replication sets are created on the consumer instance, ensuring data integrity.
    • Verification of replication sets can be done through specific URLs on both instances.

    Key Outcomes

    While bidirectional replication keeps data synchronized between instances, it has limitations such as:

    • Auto-conflict resolution is not supported, meaning simultaneous modifications to the same record can lead to merge conflicts, with the most recent update prevailing.
    • Only the Number adapter is supported; other adapters are not compatible.
    • In cases where you need to seed data or differentiate replicated data, using two one-way replication sets is recommended instead of bidirectional replication.
    • Updates triggered by business rules on the consumer instance are not replicated back to the producer instance.

    For further details on data privacy implications in IDR, consult the relevant resources. This understanding is crucial for managing data transfer between instances effectively.

    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.