mysql 5.7 主从 延迟_MySQL 5.7主从复制从零开始设置及全面详解——实现多线程并行同步，解决主从复制延迟问题！...

MySQL 5.7主从复制从零开始设置及全面详解——实现多线程并行同步，解决主从复制延迟问题！

2017年06月15日 19:59:44 蓝色-鸢尾 阅读数：2062

版权声明：本文为博主原创文章，如需转载，请注明出处！https://blog.csdn.net/xzsfg6825/article/details/73302066

使用数据库同步的方法解决数据传输的问题，但因为使用mysql 5.5版本时，设置的主从复制在数据量较大或者网络拥塞的时候延迟会更高，而且经过查资料，老版本是无法从根本上改善这个问题的。最近了解了MySQL 5.7版本的特性，知道了5.7版本的基于组提交的并行复制可以更大的改善这个问题。接下来对相关的内容进行详细的总结和概括。

一、Mysql 5.6 及更低版本的主从复制

(1) 在MySQL 5.6之前的版本里，有三个线程参与，都是单线程：Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从)。其中IO Thread线程负责从主库拿binlog并写到relaylog，sql_thread 线程负责读relaylog并执行。复制出现延迟一般出在两个地方

a、SQL线程忙不过来(可能需要应用数据量较大，可能和从库本身的一些操作有锁和资源的冲突；)

虽然主库可以并发写，但Slave_SQL_Running线程不可以并发写(主要原因)。

b、网络抖动导致IO线程复制延迟(次要原因)。

(2) MySQL从5.6开始有了多线程的概念，可以并发还原数据，即并行复制技术。多线程的思路就是把sql_thread 变成分发线程，然后由一组worker_thread来负责执行。MySQL 5.6中，设置参数slave_parallel_workers = 4，即可有4个SQL Thread(coordinator线程)来进行并行复制，其状态为：Waiting for an evant from Coordinator。但是其并行只是基于Schema的，也就是基于库的。如果数据库实例中存在多个Schema，这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形，所以基于库的并发一般是没什么用的，不过其也有一定优势：

对于可以按表分发的场景，可以通过将表迁到不同的库，来应用此策略，有可操作性。

二、Mysql 5.7 的主从复制

(1)新版本增加了一种类型，变成了两种类型

1、DATABASE 基于库的并行复制 ， 每个数据库对应一个复制线程(5.6版本就有了，然并卵)；

2、LOGICAL_CLOCK 基于组提交的并行复制方式，同一个数据库下可以有多个线程(对大多数数据库更实用)。

对于第二种类型，设置参数slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’，即可支持一个schema下，slave_parallel_workers中的worker线程并发执行relay log中主库提交的事务。

(2)从MySQL官方文件看，其并行复制的要实现的目标是支持表级的并行复制和行级的并行复制，行级的并行复制通过解析ROW格式的二进制日志的方式来完成。

(3)5.7版本基于组提交的并行复制核心思想是：一个组提交的事务都是可以并行回放的，因为这些事务都已进入到事务的prepare阶段，则说明