Altinity
Handle scenario when records could be inserted with the same timestamp(non gtid-mode)
first change : pad the timestamp with nano-seconds. this needs to be done to be able to switch between binlog and GTID in both ways second change : add a counter within the second (reset at the top of the second) third change : only persists binary log positions that are the first in their second !
Solution : add a 9 digit counter (aka nanos) in the version but reset this counter at each second transition. It gives 1 billion changes in 1s (updates as inserts have different PKs), that does not happen in MySQL.
Now there is one catch, if replication stops in the middle of a second, we need to be sure that the new changes get precedence. Start at 500M on restart then reset at the next second.
It is very unlikely we are going to stop on the same second at the next checkpoint.
The current ts_ms value that is received from debezium is the epoch time in milliseconds. Its a 12 digit number.
171 364 045 5534
Changed from using ts_ms to using debezium ts_ms as debezium ts_ms is guaranteed to be monotonically increasing.
- a counter within the ms
@subkanthi this issue is now fixed, I can not reproduce it with the new build.
