mysql 互为主备 宕机 数据丢失_MySQL复制一致性问题探索（一）

导  读

MySQL是现在最热门的开源数据库，已在互联网公司广泛应用。随着对数据库安全可控的考虑，银行业也正在进行较大规模推广，用于替代传统数据库产品。但与大多数互联网公司不同，银行业对MySQL架构提出了更高的要求，其中如何保证数据一致性是最为关心的一个问题。本文详细分析了MySQL不同复制模式下出现数据不一致的情况，提出了如何最大程度避免和解决的思路。

MySQL内建的复制功能是构建基于MySQL的大规模，高性能应用的基础。复制就是让一个MySQL服务器(MASTER)将数据通过日志的方式经过网络传送到另一台或多台MySQL服务器(SLAVE)，然后在SLAVE上重放(replay或redo)传送过来的日志，以达到和MASTER数据同步的目的。

MySQL复制的模式分为异步复制、全同步复制及半同步模式。下面将针对不同复制模式下出现数据一致性问题进行详细分析。

1.异步复制(Asynchronous replication)

主库在执行完客户端提交的事务后，会立即提交并将结果返给客户端，并不关心从库是否已经接收日志并处理，如果此时主库上已经提交的事物因为某些原因未传送到备库，同时主库发生宕机，并在此时从库提升为主，这样就会导致新主库数据缺失，从而造成主从数据不一致的情况发生。该复制模式下，这种情况是必然会发生的。过程如下图：

主库将事务写入到Binlog 文件中，并通知 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，所以此时无法保证这些 Binlog已经成功传到任何一个从库节点上。

2.全同步复制(Fully synchronous replication)

指当主库执行完一个事务，且所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以主库完成一个事务的时间会被拉长，从而全同步复制的性能必然会受到较大的影响。

全同步是在MySQL NDB Cluster上采用的复制方式，该集群在中国大陆使用极少，早些年曾在某行有过应用，不过据说坑很多，不建议采用。全复制会严重影响主库的事物提交性能，对网络要求非常严格，不适合同城、异地的架构场景。

NDB是分布式存储引擎，无共享架构，严格来说NDB节点不是复制，而是2pc，确保事务提交的强一致。

3.半同步复制(Semisynchronous replication) 

是介于全同步复制与全异步复制之间的一种复制方式。当执行完一个事务后，主库需要等待至少一个从库节点收到日志事件并刷新Binlog 到 Relay Log 文件中的ACK确认消息后，才能提交并返回给客户端确认信息，