Kristian Nielsen <knielsen@knielsen-hq.org> writes:
(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
After some tests, it seems this is indeed what is happening. Whenever a conflict in optimistic parallel replication is detected late in the execution of the conflicting transaction, rows in the mysql.gtid_slave_pos table can be left undeleted, as you see. This goes back all the way to 10.1. I'm somewhat sad to see a bug like this surface only now, it would appear that optimistic parallel replication is not much used? Or maybe the fact that the table will be cleared on server restart has made people just live with it? In any case, thanks Reinis for taking the time to report this serious issue, I'll see if I can come up with a patch to fix the problem. - Kristian.