Bidirectional replication
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.
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.