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云平台推荐
随便看看
- 2022-07-04DD命令压测、备份与还原磁盘一文详解
- 2022-02-26Linux iptables控制网络访问
- 2021-03-27MySQL GTID全局事物标识
- 2022-05-17MySQL命令统计的库大小和物理文件大小差异
- 2021-05-20Linux搭建GRE隧道教程