> I have now pushed a fix for this. I expect it will be included in the next
> release.
>
> Once again thanks for taking the time to do a good error report, glad to get
> this fixed.
Thank you for the good work, waiting for the release then.
rr
___
M
Hi Reinis,
I have now pushed a fix for this. I expect it will be included in the next
release.
Once again thanks for taking the time to do a good error report, glad to get
this fixed.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-discuss
>> 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.
I have now committed a patch that should fix this.
If you want to try it, you can find it here:
https://github.
"Reinis Rozitis" writes:
> Is there a jira/github issue I could follow?
I can put any updates in the MDEV-12147.
- Kristian.
___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https:/
> 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
Kristian Nielsen 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.
Kristian Nielsen 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.
Thanks for the additional info.
TokuDB probably isn't the most used engine with optimistic parallel
replication. I worked with a TokuDB developer some time ago to make it work,
but I'm not sure how well those fixes are maintained in MariaDB (ie. I tried
now running the testcase tokudb_rpl.rpl_para
> Do you have any errors in the error log about failure to delete rows?
Nope, no errors.
> Anything else special to your setup that might be causing this?
At some point I thought maybe the tokudb_analyze_in_background /
tokudb_auto_analyze messes things up as it does the background check (you
"Reinis Rozitis" writes:
> the table starts to grow continuously:
>
> MariaDB [mysql]> select count(*) from gtid_slave_pos;
> +--+
> | count(*) |
> +--+
> | 5577268 |
> +--+
> 1 row in set (1.553 sec)
That definitely look bad. As you say, there can be multiple rows in th
Hi,
before considering this as a bug wanted to ask in mailing list:
I know that gtid_slave_pos table can have multiple entries, but (at least on
10.3.9 but maybe also earlier (just noticed now)) while running:
slave_parallel_threads = 20
slave_parallel_mode = optimistic
the table starts to grow
11 matches
Mail list logo
