MySQL Bugs: #51697: handle equal values in "greatest timestamp wins" conflict resolution system

Bug #51697	handle equal values in "greatest timestamp wins" conflict resolution system
Submitted:	3 Mar 2010 16:39	Modified:	11 Jan 2011 10:59
Reporter:	Bogdan Kecman	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Cluster: Replication	Severity:	S4 (Feature request)
Version:	mysql-5.1-telco-6.2	OS:	Any
Assigned to:	Jonas Oreland	CPU Architecture:	Any
Tags:	ALL

Description:
When using "greatest timestamp wins", if "timestamp" value on both servers is the same then no conflict resolution is performed and this lead to different data on two masters.

The workaround would be to set the "timestamp" value to now() << 1 + 0 on one master and now() << 1 + 1 on second master and by this making sure that if events happen in same time one master always have greater final value. Problem with this workaround is that additional complexity has to be introduced (especially when using ndb-api and bypassing sql nodes).

How to repeat:
1. setup master-master cluster replication
2. insert "same id" record with different value for prop attribute and same value for timestamp value on both masters in the same time 
3. check content of the tables - it will be different

Suggested fix:
Attm the ha_ndbcluster.cc:row_conflict_fn_max ignores the equal values. If they are equal then for e.g. the one with higher server_id should be the "greatest wins".

This will not be fixed, and people will instead be recommended to use
upcoming gci-based conflict detection/resolution