NDB Cluster Replication Conflict Resolution PRIMARY KEY(NDB$server_id, NDB$source_server_id, NDB$source_epoch, NDB$count) ) ENGINE=NDB; Suppose there occur the two simultaneous transactions on the two clusters. On cluster  A , we create a new department, then move employee number 999 into that department, using the following SQL statements: BEGIN; INSERT INTO department VALUES (4, "New project", 1); UPDATE employee SET dept = 4 WHERE id = 999; COMMIT; At the same time, on cluster  B , another transaction reads from  employee , as shown here: BEGIN; SELECT name FROM employee WHERE id = 999; UPDATE department SET members = members - 1 WHERE id = 3; commit; The conflicting transactions are not normally detected by the conflict resolution mechanism, since the conflict is between a read ( SELECT ) and an update operation. You can circumvent this issue by executing SET ndb_log_exclusive_reads = 1  on the replica cluster. Acquiring exclusive read locks in this way causes any rows read on the source to be flagged as needing conflict resolution on the replica cluster. If we enable exclusive reads in this way prior to the logging of these transactions, the read on cluster  B  is tracked and sent to cluster  A  for resolution; the conflict on the employee row is subsequently detected and the transaction on cluster  B  is aborted. The conflict is registered in the exceptions table (on cluster  A ) as a  READ_ROW  operation (see Conflict Resolution Exceptions Table, for a description of operation types), as shown here: mysql>  SELECT id, NDB$OP_TYPE, NDB$CFT_CAUSE FROM employee$EX; +-------+-------------+-------------------+ | id | NDB$OP_TYPE | NDB$CFT_CAUSE | +-------+-------------+-------------------+ ... | 999 | READ_ROW | TRANS_IN_CONFLICT | +-------+-------------+-------------------+ Any existing rows found in the read operation are flagged. This means that multiple rows resulting from the same conflict may be logged in the exception table, as shown by examining the effects a conflict between an update on cluster  A  and a read of multiple rows on cluster  B  from the same table in simultaneous transactions. The transaction executed on cluster  A  is shown here: BEGIN; INSERT INTO department VALUES (4, "New project", 0); UPDATE employee SET dept = 4 WHERE dept = 3; SELECT COUNT(*) INTO @count FROM employee WHERE dept = 4; UPDATE department SET members = @count WHERE id = 4; COMMIT; SET ndb_log_exclusive_reads = 1; # Must be set if not already enabled ... BEGIN; SELECT COUNT(*) INTO @count FROM employee WHERE dept = 3 FOR UPDATE; UPDATE department SET members = @count WHERE id = 3; COMMIT; Concurrently a transaction containing the statements shown here runs on cluster  B : In this case, all three rows matching the  WHERE  condition in the second transaction’s  SELECT  are read, and are thus flagged in the exceptions table, as shown here: 4653