Details
-
Type:
Task
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: Replication
-
Labels:
Description
currently we have a status variable for the total group_commits. This compromises of group commits due to binlog_commit_wait_count, binlog_commit_wait_usec or indeed conflicting transactions that need to be in a separate group.
Showing a breakdown as to the reason of the group commit will enable a more informed tuning of the system variables controlling the group commit and also identify how often these aren't taking part in the group determination.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
MDEV-7249 Performance problem in parallel replication with multi-level slaves
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
responded and corrected in github PR: https://lists.launchpad.net/maria-developers/msg08405.html
Thanks, Daniel.
The patch is ok. Though I will remove the test case in
rpl_parallel_multilevel2, I think. The 2-second timeout could trigger on
highly loaded test hosts, which looks like it will make the test case
fail. And I don't think the test adds anything really critical over what's
in binlog_commit_wait.test.
So I will push it into 10.1, however I need to first resolve a merge problem
that is blocking the push...
The patch is ok. Though I will remove the test case in
rpl_parallel_multilevel2, I think. The 2-second timeout could trigger on
highly loaded test hosts, which looks like it will make the test case
fail. And I don't think the test adds anything really critical over what's
in binlog_commit_wait.test.
Ok - was my description on the multilevel for the reason between 1 and 3 groups right? I felt I was guessing a bit.
https://github.com/MariaDB/server/pull/30/files#diff-343103ed05549066b0de2beb82b16496R77
So I will push it into 10.1, however I need to first resolve a merge problem that is blocking the push...
to help that along...
https://github.com/MariaDB/server/pull/43 - single merge
https://github.com/MariaDB/server/pull/42 - entire 10.0 -> 10.1
Pushed to 10.1.5. Thanks, Daniel!
Pushed to 10.1.5. Thanks, Daniel!
Welcome. Thanks for the merge.
Any chance of getting this into 10.0? seems like the most invasive bit is the extra brief lock on LOCK_prepare_ordered when when fetching status variables.
I've added status variables to the KB.
> Any chance of getting this into 10.0? seems like the most invasive bit is
> the extra brief lock on LOCK_prepare_ordered when when fetching status
> variables.
Probably you should ask this on the maria-developers@ mailing list. I don't
personally have any strong opinion one way or the other.
The "normal" policy is to not introduce new features in stable releases.
> I've added status variables to the KB.
Thanks, Daniel, much appreciated.
See review comments on maria-developers@