VReplication resharding cut-over: managing conflicting updates during final synchronization

Resharding Consistency in Vitess

Vitess utilizes VReplication to move data asynchronously between sources and destinations during resharding operations. This workflow ensures that the target shards are populated while the source remains available for writes.

The final cut-over phase requires a brief write-lock on the source to synchronize the remaining binlog events. However, the behavior of the VReplication engine when encountering conflicting updates during this precise transition window remains a critical design consideration for maintaining strict data consistency.

Given the dependency on MySQL binlog formats and the coordinated sequence of VReplication streams, there is uncertainty regarding the resolution priority when the destination target and source have divergent states immediately preceding the cut-over.

• How does Vitess resolve conflicts between source and destination updates during the final synchronization phase of a resharding event?
• What mechanisms prevent data loss if a conflict occurs during the brief write-lock period?