mysql在几个大版本中的并发复制都不一样，当然做的是越来越好。
在5.6版本中
–slave-parallel-workers参数代表并行执行复制事务的slave worker线程的数量，设置未0代表禁用并行复制，最大值是1024.当并行执行设置后，sql线程充当了slave worker线程的调度器，事务是基于每个数据库的。就是基于库级别的，
由于是并发的就会导致，不同数据库上的事务在从库上应用的顺序与在主库上的顺序不同，因此检查最近执行过的事务并不能保证master上之前的事务已经在从库上被执行过了，所以，start slave until在多线程复制的情况下就不适用了。在启用了多线程复制后，slave_transaction_retries被当作成0，不能被更改。在不同库中的表中设置主外键关系，会导致并行复制变成串行模式。
slave_transaction_retries代表的如果sql线程由于死锁或事务执行执行时间超过了innodb_lock_wait_timeout的设置导致执行事务失败，还会在停止前重试该次数，默认是10次。
在5.7版本中
slave-parallel-workers代表是在并行复制中使用这么多的applier线程，还有一个协调线程，事务在这些applier线程分配的方式，是通过–slave-parallel-type参数指定的，这个参数有2个值database logical_clock.
logical_clock：master上在相同的二进制日志组中提交的事务在从库上被并发应用，根据事务的时间戳来跟踪事务间的依赖关系，方便提供额外的并行，当设置这个值的时候，可以指定binlog_transaction_dependency_tracking参数来指定在master上使用write set来替代时间戳，在8.0开始使用write set了。
database:在不同的数据库上执行的事务被并发应用，退回到5.6版本了。
当slave_preserve_commit_order设置成1的时候，你只能使用logical_clock.
当复制的拓扑是多层的时候，logical_clock在并发程度上效果可能不好，可以设置binlog_transaction_dependency_tracking来降低影响，在并发应用的时候，slave上应用的事务顺序可能不是顺序的，除非设置了slave_preserve_commit_order=1，在设置这个参数的时候，复制线程需要停止，执行的线程在提交前会等待之前所有的事务已经被提交，这个参数在启用的时候，exec_master_log_pos的位置信息也是不准确的。在5.7版本以后，多线程复制情况下事务的重试是被支持的。
mysql8版本中
slave-parallel-workers这个参数也是指定了应用线程的情况外加一个协调线程，如果你使用了多个复制通道，每个通道都有这个参数指定的线程数。binlog_transaction_dependency_tracking这个参数设置后，效果要比时间戳的方式好。在mysql8的并行复制中logical_clock也是在相同的组提交中的事务并发应用的，跟mysql5.7一样。
