多线程复制

多线程复制MTS(Mult-Threaded Slave Applier)指使用多个线程来并发应用二进制日志。
在MYSQL5.6版本中，多线程复制基于schema来实现，将多个数据库下的事务按照数据库拆分到多个线程上执行，保证数据库级别的事务一致性。
在MYSQL5.7版本后，多线程复制基于主库上并发信息来实现，主库上并发提交的事务不存在事务冲突，在从库上拆分到多个线程执行，保证实例级别的事务一致性。

设置和多线程复制类型和复制线程数：

##设置多线程复制类型和复制线程数：
SET GLOBAL slave_parallel_type='DATABASE';
SET GLOBAL slave_parallel_type='LOGICAL_CLOCK';
SET GLOBAL slave_parallel_workers =8;## 查看多线程复制类型和复制线程数
SELECT @@slave_parallel_type,@@slave_parallel_workers;

基于DATABASE的多线程复制

在MySQL 5.6中引入该特性，如果主库上存在多个数据库，每个数据库的事务相互独立于其他数据库，因此只需要保证数据库内部的事务运行顺序和主库上的运行顺序一致，就可以保证主库和从库上的数据相同。

在MYSQL中开启并行复制功能，SQL线程会变成coordinator线程，coordinator线程会对二进制日志的event进行判断：
1、如果判断事件可以被并行执行，那么选择相应worker线程应用BINLOG事件
2、如果判断事件不可以被并行执行，如DDL操作或跨schema事务，则等待所有worker线程执行完成后，再执行该BINLOG事件。
coordinator线程不仅分发BINLOG事件，也可以执行BINLOG事件。

当实例上数据库数量较少或应用主要对某个数据库进行读写，并行复制的性能可能会比单线程复制更差。
对于跨数据库的事务或跨数据库的外键，都会导致无法多线程并行执行。

基于DATABASE的多线程复制模式下执行位点问题：
1、MySQL使用Low-Water-Mark标记来最小已完成事件点，当发生宕机恢复时，根据Low-Water-Mark标记值来重放其后面的事件，而其中部分事件可能已被执行，重复执行可能会导致SQL线程异常或数据异常。
2、MySQL使用checkpint方式来推进APPLY主库BINLOG的位置，使用SHOW SLAVE STATUS命令显示的Exec_master_log_pos值是最近一次checkpint时的位点，而不是最后一个APPLY事务的值。
3、运行SQL_SLAVE_SKIP_COUNTER命令存在风险，可能会跳过其他事务。
4、对从库进行备份获取到的执行位点可能不是正确位点
5、当多个数据库执行进度相差较大时，可以使用START SLAVE UNITL SQL_AFTER_MTS_GAPS语句来等待延迟较大的数据库执行。

基于LOGICAL_CLOCK的多线程复制

在MySQL 5.7版本中引入，在主库上的某个时间点上，所有完成excution处于prepare阶段的事务都处于一个"相同的数据库版本"上，这些事务之间不存在阻塞或者依赖，因此可以赋予一个相同的时间戳；拥有相同时间戳的事务可以在从库上并行执行并且不会导致相互等待。如果事务间存在依赖，那么被阻塞的事务肯定处于Execution状态而不会进入Prepare状态。

如上图中三个事务：

1、T1事务和T2事务的Commit阶段有重合部分，T2事务和T3事务的Commit阶段有重合部分，因此T1和T2可以在从库上并发执行，T2和T3可以在从库上并发执行。

2、T1事务和T3事务的Commit阶段没有有重合部分，无法判断T3事务是否依赖于T1事务，因此T1和T3不能在从库上并发执行。

Transactions with overlapping commit window can be executed in parallel;

在MYSQL 5.7版本的二进制日志中增加了last_committed和sequence_number，sequence_number表示当前语句所使用的编号，使用last_committed表示当前语句提交时的上一次组提交事务中最大的sequence_number。

相同last_committed的事件可以并行执行，无需考虑事件中的sequence_number。

#150520 14:23:11 server id 88 end_log_pos 259 CRC32 0x4ead9ad6 GTID last_committed=0 sequence_number=1
#150520 14:23:11 server id 88 end_log_pos 1483 CRC32 0xdf94bc85 GTID last_committed=0 sequence_number=2
#150520 14:23:11 server id 88 end_log_pos 2708 CRC32 0x0914697b GTID last_committed=0 sequence_number=3
#150520 14:23:11 server id 88 end_log_pos 3934 CRC32 0xd9cb4a43 GTID last_committed=0 sequence_number=4
#150520 14:23:11 server id 88 end_log_pos 5159 CRC32 0x06a6f531 GTID last_committed=0 sequence_number=5
#150520 14:23:11 server id 88 end_log_pos 6386 CRC32 0xd6cae930 GTID last_committed=0 sequence_number=6
#150520 14:23:11 server id 88 end_log_pos 7610 CRC32 0xa1ea531c GTID last_committed=6 sequence_number=7
#150520 14:23:11 server id 88 end_log_pos 8834 CRC32 0x96864e6b GTID last_committed=6 sequence_number=8
#150520 14:23:11 server id 88 end_log_pos 10057 CRC32 0x2de1ae55 GTID last_committed=6 sequence_number=9
#150520 14:23:11 server id 88 end_log_pos 11280 CRC32 0x5eb13091 GTID last_committed=6 sequence_number=10
#150520 14:23:11 server id 88 end_log_pos 12504 CRC32 0x16721011 GTID last_committed=6 sequence_number=11
#150520 14:23:11 server id 88 end_log_pos 13727 CRC32 0xe2210ab6 GTID last_committed=6 sequence_number=12
#150520 14:23:11 server id 88 end_log_pos 14952 CRC32 0xf41181d3 GTID last_committed=12 sequence_number=13

多线程复制模式下的事务执行顺序：

MySQL通过参数slave_preserve_commit_order可以控制Slave上的binlog提交顺序和Master上的binlog的提交顺序一样，保证GTID的顺序。该参数只能用于开启了logical clock并且启用了binlog的复制。即对于多线程复制，该参数用来保障事务在slave上执行的顺序与relay log中的顺序严格一致。开启该参数可能会有一点的消耗，因为会让slave的binlog提交产生等待。

比如两个事务依次操作了2个DB：A和B，尽管事务A、B分别被worker X、Y线程接收，但是因为线程调度的问题，有可能导致A的执行时机落后于B。如果经常是“跨DB”操作，那么可以考虑使用此参数限定顺序。当此参数开启时，要求任何worker线程执行事务时，只有当前事务中之前的所有事务都执行后（被其他worker线程执行），才能执行和提交。（每个事务中，都记录了当前GTID的privious GTID，只有privious GTID被提交后，当前GTID事务才能提交）。

建议在生产环境开启该参数。