MySQL半同步复制与刷盘策略

一、关于半同步复制

1.1 什么是半同步复制？

MySQL半同步复制是介于异步和全同步之间，主库只需要等待至少一个从节点，收到并且flush binlog到relay log文件即可。主库不需要等待所有从库给主库反馈，主库只需要收到任意一个从库反馈，而且并不是从库已经完成并提交的反馈，而是从库只应用完成io_thread内容即可反馈，无需等到sql_thread的执行完成。

1.2 半同步退化参数

前面我们介绍过开启半同步参数后，在主从复制的过程中，主库至少收到一个从库回复ACK确认消息后，主库才会commit事务。那么是否意味着，只要从库不回复ACK确认消息，主库就一直不commit事务呢（业务夯住）？答案是否定的。为了避免从库未能及时回复主库ACK确认消息，而导致主库业务夯住情况的发生，（比如，主从同步延迟等场景）MySQL也提供了相关解决方案，即半同步退化机制。可以通过设置半同步退化时间，来控制上述业务持续夯住的发生。

（1）半同步退化常见日志输出

2020-01-16T14:22:11.817155+08:00 277766 [Note] Semi-sync replication switched OFF.
2020-01-16T14:22:19.891210+08:00 0 [Note] Semi-sync replication switched ON at (mysql-bin.001148, 425854004)

（2）半同步退化配置

mysql> show variables like "rpl_semi_sync_master_timeout";

二、半同步复制的两种模式

2.1 after commit

MySQL5.6的半同步参数，after commit是在主库写完bin log，在等待Slave ACK时候，虽然没有返回当前客户端，但事务已经提交，其他客户端会读取到已提交事务。如果Slave端还没有读到该事务的events，同时主库发生了crash，然后切换到备库。那么之前读到的事务就不见了，出现了幻读。

2.2 after sync

MySQL在调用binlog sync之后，engine层commit之前等待Slave ACK。这样只有在确认Slave收到事务events后，事务才会提交。在commit之前等待Slave ACK，同时可以堆积事务，利于group commit，有利于提升性能。

2.3 小结

对比after commit与after sync两种模式后，不难发现，after sync模式数据一致性更好，更适合用于高可用架构的主从复制模式中。

三、MySQL双一确认（刷盘策略）

3.1 sync_binlog

官网介绍：https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html

3.2 innodb_flush_log_at_trx_commit

官网介绍：https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit

3.3 小结

sync_binlog和innodb_flush_log_at_trx_commit是一组参数，如果需要变更其中之一的值，另一个也需要做出相同修改。默认情况下，为了保障数据安全，两个参数默认值都是1，即事务commit时立刻进行刷盘操作。如果参数设置为0，MySQL的并发性能会有一定的提升，但是基于牺牲数据安全的前提。比如：业务侧已经commit多组事务，但是由于MySQL侧不会主动进行刷盘操作，需要等待操作系统OS层面进行刷盘操作，所以一但异常（宕机、crash等）发生在操作系统OS刷盘之前，就会导致期间commit的事务数据丢失，对于高度数据敏感的业务，这种情况是不可接受的。

作者：UStarGao
链接：https://www.starcto.com/mysql/240.html
来源：STARCTO
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

UCloud新用户专属注册连接

UCloud CDN超值特惠专场

UCloud全球云主机（UHost/VPS）大促页面

UCloud快杰云主机大促页面