简单谈谈MySQL的半同步复制(简述mysql的优势)

编辑：rootadmin

推荐整理分享简单谈谈MySQL的半同步复制(简述mysql的优势)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:简述mysql,mysql的基本介绍,1.mysql,mysql的认识,简述mysql的概念及作用,mysql的概述,简述mysql的概念及作用,简述mysql,内容如对您有帮助，希望把文章链接给更多的朋友！

简介

MySQL通过复制（Replication）实现存储系统的高可用。目前，MySQL支持的复制方式有：

异步复制（Asynchronous Replication）：原理最简单，性能最好。但是主备之间数据不一致的概率很大。半同步复制（Semi-synchronous Replication）：相比异步复制，半同步复制牺牲了一定的性能，提升了主备之间数据的一致性（有一些情况还是会出现主备数据不一致）。组复制（Group Replication）：基于Paxos算法实现分布式数据复制的强一致性。只要大多数机器存活就能保证系统可用。相比半同步复制，Group Replication的数据一致性和系统可用性更高。

本文主要讨论MySQL半同步复制。

半同步复制的基本流程

MySQL半同步复制的实现是建立在MySQL异步复制的基础上的。MySQL支持两种略有不同的半同步复制：AFTER_SYNC和AFTER_COMMIT（受rpl_semi_sync_master_wait_wait_point控制）。

开启半同步复制时，Master在返回之前会等待Slave的响应或超时。当Slave超时时，半同步复制退化成异步复制。这也是MySQL半同步复制存在的一个问题。本文不讨论Salve超时的情形（不讨论异步复制）。

半同步复制AFTER_SYNC模式的基本流程

AFTER_SYNC模式是MySQL 5.7才支持的半同步复制方式，也是MySQL5.7默认的半同步复制方式：

Prepare the transaction in the storage engine(s). Write the transaction to the binlog, flush the binlog to disk. Wait for at least one slave to acknowledge the reception for the binlog events for the transaction. Commit the transaction to the storage engine(s).

半同步复制AFTER_COMMIT模式的基本流程

MySQL 5.5和5.6的半同步复制只支持AFTER_COMMIT：

Prepare the transaction in the storage engine(s). Write the transaction to the binlog, flush the binlog to disk. Commit the transaction to the storage engine(s). Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.

AFTER_SYNC和AFTER_COMMIT两种方式的小结

AFTER_SYNC：日志复制到Slave之后，Master再commit。所有在master上commit的事务都已经复制到slave。所有已经复制到slave的事务在master不一定commit了（比如，master将日志复制到slave之后，在commit之前宕机了）

AFTER_COMMIT：Master commit之后再将日志复制到Slave。所有master上commit的事务不一定复制到slave。（比如，master commit之后，还没来得及将日志复制到slave就宕机了）所有已经复制到slave的事务在master上一定commit了。很明显，AFTER_COMMIT在master宕机的情况下，无法保证数据的一致性（master commit之后，还没来得及将日志复制到slave就宕机了）。本文接下来只讨论AFTER_SYNC模式。MySQL5.7.3开始支持配置半同步复制等待Slave应答的个数：rpl_semi_sync_master_wait_slave_count 。

AFTER_SYNC模式下的异常情况分析

异常情况1：master宕机后，主备切换。

master执行事务T，在将事务T的binlog刷到硬盘之前，master发生宕机。slave升级为master。master重启后，crash recovery会对事务T进行回滚。主备数据一致。

master执行事务T，在将事务T的binlog刷到硬盘之后，收到slave的ACK之前，master发生宕机（存在pendinglog）。slave升级为master。

2.1 slave还没有收到事务T的binlog，master重启后，crash recovery会直接提交pendinglog。主备数据不一致。

2.2 slave已经收到事务T的binlog。主备数据一致。