Skip to main content

Bidirectional replication

Setting up and enabling bidirectional replication

Abstract

Bidirectional replication can be set up between two servers.

Bidirectional replication can be set up between two servers. If the two servers are called A and B, changes on server A are propagated to server B and changes on server B are propagated to server A. The logic is designed so that data changes from server A that are replicated to server B are not then replicated back to server A.

To enable bidirectional replication to a set of tables, check the Bidirectional checkbox option in your Subscription Options window.

Figure 1. Subscription Options window
Subscription Options window


Replication node IDs

Replication node IDs are required for maintaining consistent coordination between bidirectionally replicated nodes. These IDs are automatically assigned by Replication Manager. If already present in existing legacy configurations, these values are pulled in and persisted by Replication Manager.

Ping pong detection

Ping pong detection refers to avoiding replicating data already applied to target back to its source. The idea is to avoid a single change being replicated back and forth between server A and server B. Ping pong detection is provided for first-degree cycles (A > B > A). It can fail to detect more complex topologies, such as A > B > C > A. It is up to the user to develop a strategy to detect and prevent possible problems in their environment.

Data conflict management

There is no automatic conflict management in bidirectional replication, and replication conflicts should be assumed to occur in general. Refer to Replication Agent Extension Library for the FairCom replication callback SDK to implement advanced conflict management solutions.