> MySQL高可用方案很多，最常见的原生复制方案，即async、semi-sync那套，所以本文从原生复制方案为中心，讨论数据一致性。 ### 基于复制的高可用方案 * 两节点：双主、主从 * 三节点或更多：一主两从等 明确一点，这几种结构无论怎么变，无论是用MHA还是Orchestrator，还是什么第三方工具，核心点都是通过`binlog event`来传递数据给其他节点。 这种结构常见的问题： **1、延迟、复制过滤、报错等造成数据不一致：** 这个问题，一般能够通过优秀的DBA和业务开发大哥们，通过权限管理、schema设计、配置优化、SQL调优等手段处理掉，但……还有2 **2、master crash，备库没有收到binlog event：** 这个问题，有人就会说了，有个叫`semi-sync`的东西，何况5.7还优化了`semi-sync`，支持无损半同步（`lossless semi-synchronous`），但其实极端情况下，也有问题。 ### 异步复制 大家都懂。听名字和实际上都不靠谱：不管一个或多个从库是否收到了`binlog events`，主库只管产生`binlog`，极端场景下的，发生数据不一致的几率非常大。 ### 半同步复制 先简单说一下`after_commit`和`after_sync(lossless)`的差异。 ``` after_commit： 在engine commit之后等待ACK after_sync： 在engine commit之前等待ACK ``` 几个意思呢？ 因为`after_commit`模式下，先做引擎层提交，这时候其他客户端是可以会读到这个事务的。如果这时发生容灾，事务又没有传给`Slave`，容灾后客户端就读不到这个事务了，就出现了数据不一致情况。 而`after_sync(lossless)`优化了这点，即，等待`ACK`返回成功，再做引擎层提交，这样客户端1读不到，其他客户端也读不到。 我表达的不太好，俩图胜千言： ### 基于半同步复制的容灾讨论 讨论这个话题其实是非常大的，因为复制的场景很多。比如不同的GTID、auto-position、MTS等设置。 此处假设大家的MySQL实例都是经过专业DBA之手，配置好了支持`slave crash safe`的参数。 此处讨论5.7+的`after_sync(lossless)`，假设简单的一主一从（或双主都可以）为实例A->实例B #### Master Crash，未容灾： 没所谓，A拉起后继续做crash recovery，最终主从是一致的。 #### Master Crash，容灾： 1）crash时至少有一台Slave收到binlog event并成功返回了ACK给Master： 没问题，因为这种情况主从数据一致的，拉起后也不需要做额外操作。 2）Crash时binlog event发送失败： 假设产生在实例A的事务t1是：`INSERT：pk_id=11, name='张三'` 。 发生容灾，实例B成为新主，可能会产生新事务t2：`INSERT：pk_id=11, name='李四'` 实例A恢复后，做`crash recovery`，将t1直接提交，然后作为新的Slave，接收到了实例B（新主）的这条事务t2，出现了`duplicated key`，经典的`ERROR 1062`来了，设置合理的参数也没用。 其实，事务t1是要被遗弃的小可怜（鹅厂PhxSQL团队称这种事务为“Pending Binlog”） 因为也没有返回给客户端它成功提交的信息，这种情况是要回滚的，而且这种情况在`after_sync(lossless)`的设置下，也没办法的。 3）Crash时binlog event发送成功，但在等ACK，没有执行`engine commit`： 因为事务t1已经发送成功了，接管成新Master的Slave是有事务t1的，所以原Master拉起后，做`crash recovery`，也是没问题的，拉起后不需要做额外操作。 **场景2）还有什么风险？** 试想一下，如果没有pk，是不是就不会报错？ 也没办法发现拉起来的老Master实际上和新Master数据不一致了？ ### 场景2）的解决： 首先，场景2）MySQL原生复制结构是没法处理的。 但问题总要解决，为了保证整个复制节点的数据一致，考虑如下： ``` 方案1、重建节点 方案2、回滚错误事务，断点续传新增binlog ``` 方案1也就是最憨的办法，直接重建容灾后的从库，没有技术含量，xtrabackup一把梭，不说了。 方案2需要一定的开发量，参(bai)考(piao)了一下别人的做法： **微信PhxSQL：** 额外多一个BinlogSvr的中间服务。“使得Master（重启时检查本地Binlog是否和BinlogSvr集群的数据一致）和Slave（从BinlogSvr集群中获取Binlog）的数据保持一致，从而保证了整个集群中的MySQL主备间数据的一致性。” ### 结论 原生复制存在对“一致性”和“可用性”的权衡挑战。 即使是安全的配置了各种参数，使用原生复制体系和`lossless semi-sync`，也不是100%省心的（尤其是对于数据一致性要求拉满的业务）。 即使是将`rpl_semi_sync_master_timeout`设置为无穷大，也只是保证`semi-sync`不退化。 其他一致性方案或思路： ``` 1、Paxos\Raft 2、共享存储 ``` ### 参考 * 《PhxSQL设计与实现》，google一搜就有 * 《Loss-less Semi-Synchronous Replication on MySQL 5.7.2》： http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html * 淘宝内核月报 - 《MySQL 半同步复制数据一致性分析》 http://mysql.taobao.org/monthly/2017/04/01/