MySQL主从复制之并行复制说明

Coordinator 线程负责判断事务是否可以并行执行，如果可以并行就把事务分发给 WorkThread 线程执行，如果判断不能执行，如 DDL ， 跨库 *** 作 等，就等待所有的worker线程执行完成之后，再由 Coordinator 执行。

一组事务同时提交也就意味着组内事务不存在冲突，故组内的事务在从节点上就可以并发执行，问题在于如何区分事务是否在同一组中的，于是在binlog中出现了两个新的参数信息 last_committed 和 sequence_number

Enjoy GreatSQL :)

mysql5.7 并行复制 提升

分享mysql 5.7 docker 主从复制架构搭建教程，供大家参考，具体内容如下

环境版本:

MySQL : 5.7.13

Docker : 1.11.2

CentOS : 7.1

1.先在两个物理机上分别安装两个MySQL.命令如下

复制代码 代码如下:docker pull mysql:5.7.13

docker run --name anuo-mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=qaz.00JK -d mysql:5.7.13

2.在主库上创建一个复制账户

复制代码 代码如下:GRANT REPLICATION SLAVE ON *.* TO 'rep1'@'192.168.2.103' IDENTIFIED BY 'qaz.00JK'

复制账户为: rep1

指定从库的IP必须为: 192.168.2.103

复制密码为: qaz.00JK

3.修改主库的配置文件 (麻烦,应该有更方便的修改方式)

3.1先从docker拷贝配置文件到主机/root 目录:

docker cp anuo-mysql:/etc/mysql/my.cnf /root

3.2在主机打开 my.cnf , 在 [mysqld] 节点最后加上

log-bin=mysql-bin

server-id=1

3.3 再把此文件上传到docker mysql 里面覆盖

docker cp /root/my.cnf anuo-mysql:/etc/mysql/my.cnf

3.4 重启 mysql 的docker , 让配置生效

docker restart anuo-mysql

4. 修改从库的配置文件

跟第三步一样, 唯一不同是

server-id=2

5. 开始备份, 在主库执行以下命令, 让主库所有表置于只读不能写的状态, 这样达到主从库数据一致性

FLUSH TABLES WITH READ LOCK

6. 将主库的数据库备份在从库还原

用navicat for mysql 很方便 *** 作

7. 从库还原后, 释放主库的读锁, 这样主库恢复写权限

unlock tables

8.配置从库连接主库, 在从库上执行

CHANGE MASTER TO MASTER_HOST='192.168.2.108', MASTER_PORT=3306, MASTER_USER='rep1', MASTER_PASSWORD='qaz.00JK', MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=898

最后两项

MASTER_LOG_FILE 和 MASTER_LOG_POS

在主库执行 : SHOW MASTER STATUS命令可以取得

对应的字段是 File 和 Position

9. 在从库启动 slave 线程开始同步

START SLAVE

大致流程：主库将变更写binlog日志，然后从库连接到主库之后，从库有一个IO线程，将主库的binlog日志拷贝到自己本地，写入一个中继日志 relay日志中。接着从库中有一个SQL线程会从中继日志读取binlog，然后执行binlog日志中的内容，也就是在自己本地再次执行一遍SQL，这样就可以保证自己跟主库的数据是一样的。

如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，这时候从库成为了主库，那么有些数据可能就丢失了。

开启半同步复制 semi-sync ，用来解决主库数据丢失问题；

这个所谓半同步复制， semi-sync复制 ，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志 写入自己本地的relay log之后 ，接着会 返回一个ack 给主库， 主库接收到至少一个从库的ack之后才会认为写 *** 作完成了。 如果 过程出现失败 ，那么 我们的客户端就可以进行重试了 ；

主从延迟对于读写分离的涉及影响比较大

这里有一个非常重要的一点，就是 从库同步主库数据的过程是串行化的 ，也就是说 主库上并行的 *** 作，在从库上会串行执行 。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行SQL的特点，在 高并发场景下，主库大量的写，那么从库的数据一个个的读，那么就会导致从库同步一定会比主库慢一些，是有延时的 。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。（主库并发写的量级越高，从库积压的同步数据越多，延迟越高）

我们可以用 show status 看看 Seconds_Behind_Master 参数，你可以看到从库复制主库的数据落后了几ms，但是这个也不是完全准确，可以看 Seconds_Behind_Master的

对于解决主从延迟，解决方案可以从以下方面考虑

---