MySQL5.7数据强一致性与高可用(1)

在谈MySQL5.7的数据强一致性之前先来看看5.5，5.6，5.7版本做数据半同步复制时的原理。

1.半同步复制(5.5、5.6)

6.png

过程分析：
1. session发起commit请求
2. flush binlog and fsync binlog
3. InnoDB引擎层commit
4. 发送binlog日志到slave，等待slave发送回ack确认
5. slave 接收binlog写入realy log,刷盘完成发送ack确认包给master
6. master返回ok 信息给session

这种模式可能会遇到某些特殊情况导致数据不一致:

master在等待事务A返回ACK的时候宕机，此时新事务B在master宕机前开启。导致的结果可能有2种情况：

(1). 当binlog未发送到从库时：

   事务B获取到事务A提交的内容，此时宕机故障切换到slave，事务B连同事务B获取到的内容都会丢失。事务A commit也没有收到返回信息。

(2). binlog已经发送给slave

   事务B获取到事务A提交的内容，故障切换到salve ，B仍然获取到A提交的内容，没毛病。事务A commit没有收到反馈信息，若重新执行该事务，则相当于执行两次A事务.

2. 增强半同步复制(5.7)

由该参数 rpl_semi_sync_master_wait_point=AFTER_SYNC/AFTER_COMMIT 两个值选择是否启用增强半同步

当半同步模式为 AFTER_COMMIT 时，为上面分析的情况
当半同步模式为 AFTER_SYNC 模式时，则如下：

7.png

8.png

过程分析：
1. session发出commit请求
2. flush binlog and fsync binlog
3. 发送binlog到slave，等待slave发送ack确认信息
4. slave接收binlog，写入realy log，刷盘完成发送ack确认包到master
5. InnoDB引擎层commit
6. master返回commit ok信息给session

此种情况下，当事务A在等待slave的ack时宕机，此时新事务B在master宕机前开启。
(1). 事务B读取不到事务A的内容，因为事务A的engine层还没有提交。这就是无损复制。

这里面有一个问题，当从库准备返回给master ACK确认包时宕机了，也就是返回ACK给master没成功，那么会发生什么呢？嘿嘿，下面一节会讲到。

3. 半同步复制增加 ACK线程

mysql5.5 mysql5.6
(1). master dump thread 发送binlog events 给 slave 的IO thread，等待 slave 的ack回包
(2). slave 接受binlog events 写入redo log ，返回 ack 包给master dump thread
(3). master dump thread 收到ack包 ，给session返回commit ok，然后继续发送写一个事务的binlog。

mysql5.7 新增ack线程
(1). master dump thread 发送binlog events 给 slave 的IO thread，开启ack线程等待 slave 的ack回包，dump 线程继续向slaveIO thread发送下一个事务的binlog。
(2). slave 接受binlog events 写入redo log ，返回 ack 包给master ack线程，然后给session返回commit ok。

可以看到，mysql5.7半同步复制中增加了一个 ACK线程专门用来进行semi 复制的ACK确认，这提高了复制的tps。