mysql 5.7.9 并行复制

mysql 5.7.9 并行复制

背景

在生产环境mysql 5.7.9上出现了从库追不上主库的情况，复制延迟在不断增加。主库的负载比较高，TPS达到500~1000，主要是insert操作。由于插入的数据中，存在一些大文本字段，导致生成的binlog非常大，达到每秒3-4G左右。从库TPS只能达到200~300。

基于上述问题，希望通过mysql 5.7.9的并行提高优化复制效率。

第一部分：基础简介

GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。GTID实质上是由UUID+TID组成的。其中UUID是一个MYSQL实例的唯一标识。（另外还有一个UUID()函数可以生成一个UUID格式的值，该值与机器、时间等变量有关，每次调用均不太一样。select UUID(), UUID() \G）
而TID则是事务ID，随着事务提交而单调递增。
GTID的格式如下

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

GTID从mysql 5.6开始出现，主要有以下两个功能：

• 根据GTID可以确认事务是由哪个实例提交的

• GTID的存在方便了Replication的Failover

假设我现在有A-B-C主从复制集群。 A为主库，BC均为A的从库。假设A库宕机，需要将B升级为主库，同时让C变成B的从库，则会遇到以下问题：

以往，若没有使用GTID模式进行主从复制，当我需要修改复制源时，我需要使用以下命令：

CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn

而问题在于，我需要知道新的复制源的MASTER_LOG_FILE及MASTER_LOG_POS与我的从库的同步停止点对应得上才能继续同步。因为新老主库采用的MASTER_LOG_FILE及MASTER_LOG_POS是不一致的，这样就会造成麻烦。GTID可以知道我复制到了A的UUID:TID这个事务了，只要继续同步UUID:TID+1即可。甚至GTID提供了MASTER_AUTO_POSITION，只需要键入以下命令即可修改复制源。

CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION

二阶段提交

这个两阶段提交不是分布式事务的两阶段提交，而是在开启binlog之后，redo与binlog的两阶段提交。 两阶段提交，首先redo log prepare，然后写binlog，最后redo log commit。mysql把它称之为内部xa事务（Distributed Transactions），内部xa事务主要是mysql内部为了保证binlog与redo log之间数据的一致性而存在的，这也是由其架构决定的(binlog在mysql层，而redo log 在存储引擎层)

prepare阶段：
主要进行redo log 的写入（具体点说是写入磁盘）。但此时在mysql内部并不认为事务已经commit完成。

commit阶段：
主要进行binlog的写入(先利用write()将binlog内存数据写入文件系统缓存，然后利用fsync()从文件系统缓存刷到磁盘上)，最后再调用存储引擎（举个例子：innodb）

也就是三个小阶段：Flush – Sync – Commit，下面组提交有叙述。

如果redo log prepare之后，binlog之前宕机，则回滚事务，日志如下&