mysql 并行复制

814247614

　　MySQL的复制延迟是一直被诟病的问题之一，在MySQL 5.7版本已经支持“真正”的并行复制功能，官方称为为enhanced multi-threaded slave（简称MTS），因此复制延迟问题已经得到了极大的改进。总之，MySQL 5.7版本后，复制延迟问题永不存在。并行复制主要是解决sql_thread在高并发环境下，存在性能瓶颈。mysql5.7并行复制的思想简单易懂，一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）。
　　为了兼容MySQL 5.6基于库的并行复制，5.7引入了新的变量slave-parallel-type，其可以配置的值有：
　　（1）DATABASE：默认值，基于库的并行复制方式
　　（2）LOGICAL_CLOCK：基于组提交的并行复制方式
　　操作步骤:
　　数据库版本信息

　　复制类型 基于binlog文件名和位置【也可采用GTID方式】

　　在slave 的my.cnf增加配置，然后重启slave。
　　[mysqld]
　　slave-parallel-type=LOGICAL_CLOCK
　　slave-parallel-workers=8
　　master_info_repository=TABLE
　　relay_log_info_repository=TABLE
　　relay_log_recovery=ON
　　重新start slave;发现有8个coordinator线程。

　　如何知道事务是否在一组中，因为原版的MySQL并没有提供这样的信息。在MySQL 5.7版本中，其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能，即将参数gtid_mode设置为OFF呢？故MySQL 5.7又引入了称之为Anonymous_Gtid的二进制日志event类型。

　　last_committed值相同的为一组，可以并行执行。

　　监控并行复制的信息
　　"root@localhost:mysql9000.sock  [performance_schema]>show tables like 'replication%';
　　+---------------------------------------------+
　　| Tables_in_performance_schema (replication%) |
　　+---------------------------------------------+
　　| replication_applier_configuration           |
　　| replication_applier_status                  |
　　| replication_applier_status_by_coordinator   |
　　| replication_applier_status_by_worker        |
　　| replication_connection_configuration        |
　　| replication_connection_status               |
　　| replication_group_member_stats              |
　　| replication_group_members                   |
　　+---------------------------------------------+
　　8 rows in set (0.00 sec)
　　并行复制配置与调优
　　master_info_repository
　　开启MTS功能后，务必将参数master_info_repostitory设置为TABLE，这样性能可以有50%~80%的提升。这是因为并行复制开启后对于元master.info这个文件的更新将会大幅提升，资源的竞争也会变大。在之前InnoSQL的版本中，添加了参数来控制刷新master.info这个文件的频率，甚至可以不刷新这个文件。因为刷新这个文件是没有必要的，即根据master-info.log这个文件恢复本身就是不可靠的。在推荐将master_info_repository设置为TABLE，来减小这部分的开销。
　　slave_parallel_workers
　　若将slave_parallel_workers设置为0，则MySQL 5.7退化为原单线程复制，但将slave_parallel_workers设置为1，则SQL线程功能转化为coordinator线程，但是只有1个worker线程进行回放，也是单线程复制。然而，这两种性能却又有一些的区别，因为多了一次coordinator线程的转发，因此slave_parallel_workers=1的性能反而比0还要差，有20%左右的性能下降。
　　这里其中引入了另一个问题，如果主机上的负载不大，那么组提交的效率就不高，很有可能发生每组提交的事务数量仅有1个，那么在从机的回放时，虽然开启了并行复制，但会出现性能反而比原先的单线程还要差的现象，即延迟反而增大了。