> 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.
Glad you were able to pinpoint the issue. > 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? Since it's not a default it's probably only interesting for those having trouble with slave lag (being single thread/cpu bound). It could be not very noticeable in case there are multiple databases/domains with less conflicts (in my case there are only 1-2 large databases) also I myself only noticed it because of the toku background checks on unusual high row number in the log. Otherways there is usually not much reason to check the mysql system tables. > 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. Thx and looking forward to it. Is there a jira/github issue I could follow? rr _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
