MySQL 集群一致性问题

主从复制

下图是主从复制的原理图。

主从复制整体分为以下三个步骤：

1. 主库将数据库的变更操作记录到Binlog日志文件中

2. 从库读取主库中的Binlog日志文件信息写入到从库的Relay Log中继日志中

3. 从库读取中继日志信息在从库中进行Replay,更新从库数据信息

在上述三个过程中，涉及了Master的BinlogDump Thread和Slave的I/O Thread、SQL Thread，它们的作用如下：

• Master服务器对数据库更改操作记录在Binlog中，BinlogDump Thread接到写入请求后，读取Binlog信息推送给Slave的I/O Thread。

• Slave的I/O Thread将读取到的Binlog信息写入到本地Relay Log中。

• Slave的SQL Thread检测到Relay Log的变更请求，解析relay log中内容在从库上执行。

异步复制

下图是异步复制的时序图。

mysql主从复制存在的问题：

• 主库宕机后，数据可能丢失

• 从库只有一个SQL Thread，主库写压力大，复制很可能延时

半同步复制

​ 为了提升数据安全，MySQL让Master在某一个时间点等待Slave节点的 ACK（Acknowledgecharacter）消息，接收到ACK消息后才进行事务提交，这也是半同步复制的基础，MySQL从5.5版本开始引入了半同步复制机制来降低数据丢失的概率。

介绍半同步复制之前先快速过一下 MySQL 事务写入碰到主从复制时的完整过程，主库事务写入分为 4个步骤：

• InnoDB Redo File Write (Prepare Write)

• Binlog File Flush & Sync to Binlog File

• InnoDB Redo File Commit（Commit Write）

• Send Binlog to Slave

当Master不需要关注Slave是否接受到Binlog Event时，即为传统的主从复制。

当Master需要在第三步等待Slave返回ACK时，即为 after-commit（Master先提交，等Slave ACK以后再，回复客户端），半同步复制（MySQL 5.5引入）。

当Master需要在第二步等待 Slave 返回 ACK 时，即为 after-sync（Master先写binlog，等Slave ACK以后再提交），增强半同步（MySQL 5.7引入）。

下图是 MySQL 官方对于半同步复制的时序图，主库等待从库写入 relay log 并返回 ACK 后才进行Engine Commit。

问题：增强型的半同步复制可以完全保证数据的一致性吗？

参考：

http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html

http://www.slideshare.net/andrewjamesmorgan/mysql-high-availability-solutions-feb-2015-webinar

http://mysql.taobao.org/monthly/2017/04/01/

https://cloud.tencent.com/developer/article/1042773

https://www.modb.pro/db/54339

场景：Master Crash且切换Master

旧Master Crash时，已经收到至少一台Slave的ACK并执行Engine Commit。

​ 数据已复制到至少一台Slave，该Slave与旧Master的数据保持一致。

旧Master处于Wait ACK阶段时Crash，旧Maste