版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sun_ashe/article/details/84109294
文章目录
半同步复制如何应对各种异常情况？
全篇以MySQL-5.7 after_sync模式半同步为背景，sync_binlog=1.
对外承诺的数据零丢失，通过半同步复制究竟能实现吗？为了能够回答这个问题，我们必须对半同步复制中可能出现的任何异常情况进行描述，并且了解故障时的master-slave数据状态。
一、准备知识
事务提交会经历哪些阶段
- flush binlog
将每一个线程中缓存的binlog文件写到binlog cache中(binlog_cache_size)
- sync redo
根据innodb_flush_log_at_trx_commit=1的设置，事务提交时，redo必须落盘。
- sync binlog
将binlog cache 写入磁盘文件
- send binlog
触发dump线程发送binlog给slave
- read ack
读取slave返回的ACK信息
- commit
在Innodb存储引擎中进行提交，包括释放undo，释放锁资源等。
- 返回给客户端提交结果
何为半同步复制
以MySQL-5.7 semisync after_sync为例，半同步复制解释为如下：
master端事务提交时，在binlog落盘之后，必须等待slave返回ack信息，才可以继续下面的操作。至于什么ACK,ACK具体包含了什么，其他地方有讲到。sync binlog是事务提交过程其中的一个阶段。
二、可能出现哪些异常以及如何解决
事务提交过程的各个阶段以及时间顺序如下图，根据下图，可以假设出一系列的故障场景，以及面对这些场景，应该如何解决？
master 在flush binlog之前宕机
-
宕机瞬间情况描述：
- master在flush binlog之前宕机，客户端未收到commit成功的信息。
- binlog未落盘
- redo可能落盘，也可能没有，因为存在一个后台线程，在没间隔innodb_flush_log_at_timeout之后，进行redo的刷盘操作。
- slave未收到此事务的binlog，slave中不会存在此数据。
-
假设只有一个半同步slave，并且rpl_semi_sync_master_wait_for_slave_count=1,那么对应的切换逻辑如下：
- 查看relay log是否被消费完成
- 切换为master（通过域名或者SIP，入口改变应该注意的事项不在本次讨论范围之内，比如说arp，DNS缓存等等）
-
切换后的master修复
- binlog中不存在对应的提交失败的事务
- redo中可能有，也可能没有
- MySQL会回滚掉相关提交失败的事务
- 数据和半同步 slave保持一致。
自己可以尝试分析下面这些场景，并进行描述。明天再更新
master 在flush binlog 之后，send binlog之前宕机
master 在send binlog之后，收到ack之前宕机
等等。