分布式数据库PhxSQL设计与实现的实例分析

　　“本文详细描述了PhxSQL的设计与实现。从MySQL的容灾缺陷开始讲起，接着阐述实现高可用强一致的思路，然后具体分析每个实现环节要注意的要点和解决方案，最后展示了PhxSQL在容灾和性能上的成果。”

　　设计背景

　　互联网应用中账号和金融类关键系统要求和强调强一致性及高可用性。当面临机器损坏、网络分区、主备手工或者自动切换时，传统的MySQL主备难以保证强一致性和高可用性。PhxSQL将MySQL集群构建在一致性完善的Paxos协议基础上，保证了集群内MySQL机器之间数据的强一致性和整个集群的高可用性。

　　原生MySQL的容灾缺陷

　　MySQL容灾方案

　　MySQL有两种常见的复制方案，异步复制和半同步复制。

　　1. 异步复制方案

　　Master对数据进行commit操作后再将数据异步复制到Slave。

　　但数据无法保证成功复制，也就无法保证MySQL主备间的数据一致性，如图1所示。

　　图1 MySQL异步复制流程

　　2. 半同步复制方案

　　Master对数据进行commit操作前将数据复制到Slave，确认复制成功后再对数据进行commit操作。

　　绝大多数情况下，半同步复制能保证MySQL主备间的数据一致性，如图2所示。

　　图2 MySQL半同步复制流程

　　MySQL重启流程

　　半同步方案中的“半”是指Master在等待Slave的ACK失败时将退化成异步复制。同时，MySQL在重启时也不会执行半同步复制。

　　如图3中的id（Gtid）=101数据是Master机器中新写入到Binlog File的Binlog数据。但Master在复制数据到Slave的过程中MySQL宕机导致复制失败。MySQL重启时，数据（id=101）会被直接进行commit操作，随后再将数据异步复制到Slave。（下文将已经写入到Binlog File但未进行commit操作的数据（id=101）称为Pending Binlog。）

　　图3 MySQL重启时直接提交Pending Binlog

　　该情况下MySQL容易出现Master-Slave之间数据不一致的情况，官方也描述了该问题。