Handling Write Conflicts under Multi-Master Replication (1)-Synchronous and Asynchronous Conflict Detection and Conflict Avoidance

The biggest problem of multi-master replication: write conflicts may occur, which must be resolved.

For example, two users edit the wiki at the same time, as shown in Figure-7.User 1 changes the page title from A->B, and User 2 changes the title from A->C at the same time.Each user's changes are successfully committed to the local master node.But when asynchronously replicating to each other, a conflict is found.Normal master-slave replication does not have this problem.

3.2.1 Synchronous and asynchronous conflict detection

If a master-slave replicated database, the second write request will:

• Blocks until the first write is complete
• Or aborted, forcing the user to retry

Under the multi-master replication model, both writes succeed, and conflicts can only be detected asynchronously at a later point in time, when it is too late to ask the user to resolve the conflict.

Theoretically, synchronization conflict detection can be achieved, that is, waiting for the write request to complete the synchronization of all replicas, and then notifying the user that the write is successful.But this will lose the advantage of multi-master: allowing each master to accept write requests independently.Therefore, if you really need synchronization conflict detection, you should consider using master-slave replication with a single master node!

3.2.2 Avoiding conflicts

The best strategy for dealing with conflicts: avoid them, if the application layer can guarantee that all write requests for a particular record go through the same master, there will be no conflicts.In practice, due to the poor conflict resolution implemented by many primary replication models, direct conflict avoidance is the recommended preferred solution.

If users need to edit their own data, it can ensure that requests from specific users are always routed to a specific IDC and read/write using the primary node of that IDC.Different users may correspond to different primary data centers (for example, according to the user's geographic location), but from the user's point of view, this is basically equivalent to the master-slave replication model.

However, it may sometimes be necessary to change the pre-designated primary node, possibly because:

• IDC failure, traffic needs to be rerouted to another IDC
• Or possibly because the user has roamed to another location, near a different IDC

At this time, the conflict avoidance method is no longer effective, and there must be a plan to deal with the possibility of simultaneous writing by different master nodes.