Conflict detection v7

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 three-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 might 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 from the current column value on target primary node B, the transaction is marked as an update/update conflict. If a related row isn't found on the target primary node, it's 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 isn't 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 was selected for the specific table. If a strategy is found, it's applied accordingly and the conflict status is marked as resolved. If a strategy can't 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.
• The primary node C changes are replicated to nodes A and B.