MySQL Bugs: #85977: The doc. of slave-parallel-type=LOGICAL

Bug #85977	The doc. of slave-parallel-type=LOGICAL_CLOCK wrongly reference Group Commit.
Submitted:	18 Apr 2017 2:02	Modified:	23 Oct 16:38
Reporter:	Jean-François Gagné	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.7 and 8.0	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Hi,

in [1] and [2], I can read: "Transactions that are part of the same binary log group commit on a master are applied in parallel on a slave".

[1]: https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_slave...

[2]: https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html#option_mysqld_slave...

The reference to Group Commit here is outdated.  MySQL 5.7.2 was using Group Commit to identify parallelism on the master (see Bug#71523 for some historical information), but since MySQL 5.7.6, extra fields are added to track last lock acquisition.  Here is a reference to MySQL 5.7.6 release notes ([3]): 

"Replication: A new more general purpose parallelization algorithm is now used when slave_parallel_type=LOGICAL_CLOCK, [...]. Now even two concurrent transactions on a master can execute in parallel on a slave, if they hold all of their locks on the master. Additionally, transaction dependency is now tracked on the slave through extra fields added to replication transactions in the binary log."

[3]: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html

Some more explanations about those fields are given in a blog post that I wrote some time ago ([4]).

[4]: http://jfg-mysql.blogspot.com/2017/02/metric-for-tuning-parallel-replication-mysql-5-7.htm...

Please update the documentation to reflect the new algorithm.

Many thanks,

JFG

How to repeat:
Documentation bu.

Suggested fix:
Update the documentation to reflect the new algorithm.

Hi,

in [1] and [2], I can read: "Transactions that are part of the same binary log group commit on a master are applied in parallel on a slave".

[1]: https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_slave...

[2]: https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html#option_mysqld_slave...

The reference to Group Commit here is outdated.  MySQL 5.7.2 was using Group Commit to identify parallelism on the master (see Bug#71523 for some historical information), but since MySQL 5.7.6, extra fields are added to track last lock acquisition.  Here is a reference to MySQL 5.7.6 release notes ([3]): 

"Replication: A new more general purpose parallelization algorithm is now used when slave_parallel_type=LOGICAL_CLOCK, [...]. Now even two concurrent transactions on a master can execute in parallel on a slave, if they hold all of their locks on the master. Additionally, transaction dependency is now tracked on the slave through extra fields added to replication transactions in the binary log."

[3]: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html

Some more explanations about those fields are given in a blog post that I wrote some time ago ([4]).

[4]: http://jfg-mysql.blogspot.com/2017/02/metric-for-tuning-parallel-replication-mysql-5-7.htm...

Please update the documentation to reflect the new algorithm.

Many thanks,

JFG

Hello Jean,

Thank you for the report and feedback!

Thanks,
Umesh

Posted by developer:
 
This isn't Group Replication. Category changed.

I am very disappointed that this documentation bug, verified in 2017, is still not fixed.

The links and quotes from the original bug are out-dated by the "terminology update", updated below.

Thanks for removing that confusion, J-F

--- Update below.

In [1], I can read: "Transactions that are part of the same binary log group commit on a source are applied in parallel on a replica.".

[1]: https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_para...