Bidirectional replication

  • Release version: Zurich
  • Updated July 31, 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) enables seamless two-way data synchronization between a producer and a consumer instance. Changes, including inserts and updates, on either instance are replicated to the other, ensuring identical tables across both instances. For example, enabling bidirectional replication on the Incidents table keeps incident records synchronized between two instances.

    Show full answer Show less

    How It Works

    To facilitate bidirectional data flow, the system creates a producer replication set on the consumer instance and a consumer replication set on the producer instance. The replication sets on the original producer instance include a reverse suffix (a randomly generated number appended), indicating the corresponding consumer replication set which is read-only. This setup allows data to flow back and forth while maintaining control over replication directions.

    Key Considerations and Limitations

    • No auto-conflict resolution: If the same record is modified simultaneously on producer and consumer instances, merge conflicts occur. The most recent update overwrites the other, potentially causing data discrepancies.
    • Adapter support: Only the Number adapter is supported in bidirectional replication; other adapters are not compatible.
    • Business rule updates: Updates triggered by business rules on the consumer instance after record insertion do not replicate back to the producer instance.

    When to Use One-Way Replication Instead

    In scenarios requiring differentiated data replication using adapters, or when seeding data from one instance to another in both directions, it is recommended to use two one-way replication sets rather than bidirectional replication. This approach offers more control and avoids potential conflicts inherent in bidirectional setups.

    Verifying Replication Status

    Customers can verify the replication status by querying the IDR statistics on both producer and consumer instances using the provided XML stats URLs, helping ensure replication sets are correctly configured and active.

    Additional Considerations

    For customers concerned with data privacy implications related to bidirectional replication and data transfer between instances, it is advised to consult the data privacy documentation specific to IDR to understand compliance and security aspects thoroughly.

    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.