Issue with _version getting "reset"

[aaroncueckermann]

The _version column is not consistently increasing after an initial sync. I think because potentially a restart is occuring and the latest _version is only persisted in memory.

This would mean updates to rows are not reflecting properly as they have a smaller version than the current version and are getting merged away.

On a side not it would be helpful to be able to define our own ver column for tables.

[bakwc]

Thank you for the report! Yeah, version should be persistent, will prepare a fix.
UPD. Actually versions are already stored persistently, will try to reproduce, but some steps would be helpful.
Probably it's related to multi-threaded initial replication, i will double check it save correct counters for multi-threaded case.

[aaroncueckermann]

Hi sorry for the delay in my response and thank you for the speed of yours. Below is the non sensitive part of the configuration file, currently only 1 table is being replicated.

binlog_replicator:
data_dir: '/home/ec2-user/binlog/'
records_per_file: 100000
initial_replication_threads: 4
binlog_retention_period: 86400

The issue seemed to have occured immediately after initial replication and the _version of new inserts/updates reset to 0. Also please note the max _version in the table was ~COUNT(DISTINCT(id))/Number of threads which I'm guessing is unintentional.

We have got around the issue temporarily we hope by setting the _version of all rows to 0 after initial replication.

[bakwc]

Fixed in v0.0.78

Also please note the max _version in the table was ~COUNT(DISTINCT(id))/Number of threads which I'm guessing is unintentional.

Yeah, but not an issue, after initial replication finished we could continue starting with maximum existing version, even if the all have 0 version during initial replication it will work fine.