Kristian Nielsen <knielsen@knielsen-hq.org> writes:
It is cool that optimistic replication works well in your setup to avoid slave lag (but not cool that it causes this problem). I will try to see if I can reproduce with simple test-generated traffic. But if you know of a way I could reproduce that would be useful.
I seem to be able to reproduce easily with just the standard testcase in the source tree. Ie. I added a select from mysql.gtid_slave_pos to tokudb_rpl.rpl_parallel_optimistic and I see extra rows at the end of the test: select * from mysql.gtid_slave_pos order by domain_id, sub_id; domain_id sub_id server_id seq_no 0 8 1 8 0 11 1 11 0 12 1 12 0 70 1 70 0 71 1 71 0 73 1 73 0 126 1 126 0 127 1 127 But adding debug printout, I can see the rows being deleted: delete -1-8 sub=8 committing... So somehow the delete is getting lost afterwards, I'll try to dig a bit deeper. But I should have the info from you I need for now, thanks for reporting this. If you want a work-around for now, then it should be ok to periodically delete (eg. a cron job) all rows in mysql.gtid_slave_pos except the one with the highest sub_id within each domain_id. (Hm. Actually... if a conflict is detected _after_ the transaction has deleted old rows from the mysql.gtid_slave_pos table, then the deletions will be rolled back along with the conflicting transaction, and it seems we will get old rows left-over just as you see... if that is what is happening here, then that seems quite a serious bug, and I wonder how it has been able to go undetected for so long... or maybe something else is going on). - Kristian.