MySQL 的三类复制方式：异步、半同步、组复制（15/32）

异步复制、半同步复制、组复制——高可用、一致性、性能三类架构要素的三种折衷

《数据库架构与实践》第 15 篇：MySQL 三类复制方式的原理与折衷。

上一篇《数据库扩展性架构实践》聊的是数据库架构设计中的scalability实践，并没有解决availability与consistency的问题。

数据库架构设计的过程中，如何折衷高可用与一致性的问题呢？

前面的文章聊过，高可用的核心方法论是：冗余（replication） + 故障自动转移（fail-over）。

最容易想到的，是数据库主从集群，每份数据都进行复制，每个实例都独享 DISK/MEM/CPU 资源，避免实例之间的资源竞争。

如上图所示：

（1）把整体数据存储复制了N份，每份之间数据都一样；

（2）每份数据的 DISK/MEM/CPU 都在一个DBMS进程内，部署在一台服务器上；

（3）每份数据的资源之间没有竞争；

理想很丰满，现实很骨感，思路没问题，但实际执行“复制”的过程中，会碰到一些问题。

以MySQL为例，有3种常见的复制方式：

（1）异步复制；

（2）半同步复制；

（3）组复制；

异步复制（Asynchronous Replication）

又叫主从复制（Primary-Secondary Replication），是互联网公司用的最多的数据复制与数据库集群化方法，它的思路是，从库执行串行化后的主库事务。

其核心原理如上图所示：

（1）第一条时间线：主库时间线；

– 主库执行事务

– 主库事务串行化binlog

– binlog同步给从库

– 主库事务提交完成

（2）第二条/第三条时间线：从库时间线；

– 收到relay log

– 执行和主库一样的事务

– 生成自己的binlog（还可以继续二级从库）

– 从库事务提交完成

从这个时间线可以看到：

（1）主库事务提交；

（2）从库事务执行；

是并行执行的，主库并不能保证从库的事务一定执行成功，甚至不能保证从库一定收到相关的请求，这也是其称作“异步复制”的原因。

半同步复制（Semi-synchronous Replication）

为了解决异步复制中“不能保证从库一定收到请求”等问题，对异步复制做了升级。

其核心原理如上图所示：

（1）第一条时间线：主库时间线；

– 主库执行事务

– 主库事务串行化binlog

– binlog同步给从库

– 等从库确认收到请求，主库事务才提交完成

（2）第二条/第三条时间线：从库时间线；

– 收到relay log

– 执行和主库一样的事务，并给主库一个确认

– 生成自己的binlog（还可以继续二级从库）

– 从库事务提交完成

从这个时间线可以看到：

（1）主库收到从库的ACK，才会提交；

（2）从库收到请求后，事务提交前，会给主库一个ACK；

半同步复制存在什么问题呢？

（1）主库的性能，会受到较大的影响，事务提交之前，中间至少要等待2个主从之间的网络TTL；

（2）从库仍然有延时，主从之间数据仍然不一致；

（3）主从角色有差异，主节点仍然是单点；

大数据量，高并发量的互联网业务，一般不使用“半同步复制”，更多的公司仍然使用“异步复制”的模式。

最后是MySQL5.7里，新提出的MySQL组复制。

组复制（MySQL Group Replication，MGR）

MGR有一些帅气的能力：

（1）解决了单点写入的问题，一个分组内的所有节点都能够写入；

（2）最终一致性，缓解了一致性问题，可以认为大部分实例的数据都是最新的；

（3）高可用，系统故障时（即使是脑裂），系统依然可用；

如上图所示：

（1）首先，分组内的MySQL实例不再是“主从”关系，而是对等的“成员”关系，故每个节点都可以写入；

（2）其次，增加了一个协商共识的认证（certify）环节，多数节点达成一致的事务才能提交；

Galera也是此类机制。

总结

结尾稍作总结，为了折衷数据库高可用，一致性，性能等架构设计要素，一般有三类常见复制方式：

（1）异步复制，传统主从，互联网公司最常用；

（2）半同步复制，从库确认，主库才提交；

（3）组复制，MySQL 5.7的新功能，核心在于分布式共识算法；

检验一下

三类复制解决了「怎么复制」，但主从架构下还有一个经典问题：主从延时会读到旧数据，怎么解？——第 16 篇《MySQL 主从一致性，架构优化的 4 种方法》。

知其然，知其所以然。思路比结论更重要。