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

本文主要是介绍半同步复制中可能出现的异常情况以及应该如何应对？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

半同步复制如何应对各种异常情况？
- 一、准备知识
- - 事务提交会经历哪些阶段
  - 何为半同步复制
- 二、可能出现哪些异常以及如何解决
- - master 在flush binlog之前宕机
  - master 在flush binlog 之后，send binlog之前宕机
  - master 在send binlog之后，收到ack之前宕机

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

全篇以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保持一致。