Conflict Detection v6.2

This section discusses the synchronization process and conflict detection.

When synchronization replication occurs, either on demand or on a scheduled basis, each of the primary node changes is pushed to the other primary nodes. See Multi-Master Parallel Replication for information on this process.

Using a 3-node example the following describes the conflict detection process.

• The replication server loads the first set of pending transactions from primary node A. Transactions are processed on a transaction set basis. (The same process is used for single-master replication.) All pending transactions are grouped in one or more transaction sets to avoid loading a very large chunk of rows in memory that may result in an out of heap space issue.
• For an update transaction, the replication server queries the first target primary node B to load the related row. If the old column value on the source primary node A is different than the current column value on target primary node B, the transaction is marked as an update/update conflict. If a related row is not found on the target primary node, it is marked as an update/delete conflict.
• For a delete transaction, the replication server queries the target primary node to load the related row. If a related row is not found on the target primary node, the transaction is marked as a delete/delete conflict.
• When a conflict is detected, the conflict information such as the transaction ID, conflict type, and conflict detection timestamp are logged in the conflict table on the target primary node.
• For a conflicting transaction, the replication server checks if any conflict resolution strategy has been selected for the specific table. If a strategy is found, it is applied accordingly and the conflict status is marked as resolved. If a strategy cannot be applied, the conflict status is marked as unresolved (also called pending).
• If no conflict is detected, the transactional change is replicated to the target primary node and the transaction status for that target node is marked as completed in the source primary node control schema. A transaction status mapping for each target primary node is maintained on all primary nodes. For example node A contains two mappings of status – one for node B and another for node C.
• All of these prior steps are repeated to process and replicate all pending transaction sets available on primary node A to primary node B.
• Next, the publication server proceeds to replicate primary node A pending transactional changes to the next target primary node, C.
• Once the primary node A changes are replicated to nodes B and C, the publication server replicates the pending changes available on primary node B to nodes A and C.
• Finally, the primary node C changes are replicated to nodes A and B.