半同步复制中可能出现的异常情况以及应该如何应对？

半同步复制如何应对各种异常情况？

全篇以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之前宕机

等等。