maria-discuss team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> 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.