MySQL高可用架构的演进 _高可用架构

MySQL是数据库领域当之无愧的霸主之一，其在各行各业被广泛应用，随着广泛使用，对于MySQL本身的高可用性的要求就是不可避免的话题，而MySQL的高可用方案也随着MySQL功能的完善经历了多次升级，本文将对MySQL的各种高可用架构进行分析，以此来了解架构的演进。
冗余是高可用设计的核心高可用的核心是避免单点故障（SPOF），而避免单点故障的最经典的解决方案是增加冗余。
不同的高可用方案在冗余方式和冗余的程度上有所差别。
冗余方式上面，有些是在底层存储上进行冗余，有些是对整个主机进行冗余，有些是跨IDC的冗余。
冗余程度上面，有些是灾备级别允许一定程度的数据丢失，有些也是要求数据的强一致性。
MySQL的各种高可用方案的核心就是围绕着冗余的设计展开。
MySQL复制技术发展史MySQL的高可用方案基于MySQL的复制技术，复制技术的核心就是增加一个MySQL节点的冗余。
1. MySQL Replication引入
2000年，MySQL 3.23.15版本引入了MySQL Replication技术，一经推出就得到了较为广泛的使用。Replication是一种异步的数据复制机制，实现的是近实时的数据同步效果。此时的Replicaton主要通过两个线程实现，一个在Master节点，一个在Slave节点。Slave首先通过Master获取到数据变动的event，然后将这个event在Slave节点进行replay重放。
这种方式存在一个比较明显的缺点，那就是replay会涉及到数据的写入，属于IO操作，速度比较慢，因为读取event和replay是在同个流程中，replay速度慢会导致读取event的缺速度也比较慢，当主节点写入的速度较快的时候，就会导致大量主备延迟，binary log会积压大量没有备份到Slave的情况，一旦Master节点出问题，Slave节点启用的话会出现大量数据落后的不一致情况，且Slave节点也无法作为读节点对外提供服务。
2. Relay Log引入
2002年，MySQL4.0.2引入了relay log,将Slave端读取event和数据replay分开成了两个流程，分别由IO线程和SQL线程两个线程负责。其中，IO线程负责从Master节点读取event，然后写入本地的relay log，SQL线程从relay log中读取event然后执行，将数据写入本地库。这样子一来，即使SQL线程执行缓慢，也只是relay log挤压，Master的binary log会通过IO线程尽可能快地同步到Slave节点，一旦Master出问题，切换到Slave，不会出现大量数据丢失不一致的情况，虽然还是有可能部分数据未及时通过IO线程写入relay log,但是程度大大地减轻了。

文章插图

文章插图

3.半同步复制引入
2010年，为解决异步复制Slave节点可能在Master宕机的情况下丢失binary log的问题，引入了半同步复制。在半同步复制的机制下，Master节点在应答客户端提交的事务之前需要保证至少一个Slave接收到Master的event并写realy log成功。
当然半同步还是存在一些问题：
1、解决了Master宕机情况下relay log丢失的问题，但是仍然非强一致性，relay log可能还未被SQL线程写入本地库，此时的查询仍然会有数据落后的可能。
2、主节点宕机，binary log还未传给半同步节点，但是已经写入本地binary log，此时切换到半同步节点运行，等待原主节点恢复以后，已经写入的binary log会被继续传给半同步节点，可能造成主键冲突。
3、无法很好的支持故障自动切换的场景。

文章插图

4.组复制的引入
2016年，MySQL5.7.17版本引入了Group Replication技术，这是一个“逻辑上”的同步的机制，在第一个节点收到一个事务时，会将事务广播到集群中的其他节点，等收到过半数节点同意以后，事务会在各个节点上独立提交，也就是说各个节点只是在决定事务是否冲突、能否提交的阶段是同步的，而事务的提交是异步的。Group Replication技术是一项支持高可用、强数据一致性的方案，并且最重要的是将不再仅仅只是着眼于提供一个冗余备份，而是从一个集群的角度上来保障高可用和数据一致性，支持流控、故障自动切换等特性，运维比较简单，在高可用和性能上实现了较好的平衡，整体优缺点总结如下：
优点：
1、强一致性：基于分布式paxos变种协议实现组复制，保证数据强一致性；
2、高容错性：自动故障和节点异常检测机制，集群过半数节点正常运行就可以保证集群的可用性。