MySQL高可用架构

引言

“高可用”是互联网一个永恒的话题,先避开MySQL不谈,为了保证各种服务的高可用有几种常用的解决方案。

  1. 服务冗余:把服务部署多份,当某个节点不可用时,切换到其他节点。服务冗余对于无状态的服务是相对容易的。
  2. 服务备份:有些服务是无法同时存在多个运行时的,比如说:Nginx的反向代理,一些集群的leader节点。这时可以存在一个备份服务,处于随时待命状态。
  3. 自动切换:服务冗余之后,当某个节点不可用时,要做到快速切换。

总结起来就是 冗余+故障转移

MySQL高可用

MySQL的高可用也是同样的思路,首先要有多个MySQL实例提供服务,其次就是当某个实例挂掉时,可以自动切换流量。同时MySQL作为存储,节点之间数据同步也是一个难题(换句话说,有状态的服务都面临这个问题)。

一主一备:

MySQL的各种高可用架构,都脱离不了MySQL实例之间的数据同步,因此,我们先介绍下最简单的一主一备架构下MySQL的数据同步流程。

MySQL高可用架构_第1张图片 上图是主从数据同步的一个示意图。

  • Master节点有Dump进程把binlog中的数据发送到Slave节点,
  • Slave节点有IO进程接收数据写入relay log,
  • Slave节点的SQL进程根据relay log写入数据。

这里还要延伸一点,binlog存在三种形式:Statement、Row、Mixed。

  • Statement:就是把每一条SQL记录到binlog中。
  • Row:是把每一行修改的具体数据记录到binlog中。
  • Mixed:MySQL会灵活的区分,需要记录sql还是具体修改的记录。

只记录SQL的话binlog会比较小,但是有些SQL语句在主从同步数据的时候,可能会因为选择不同的索引在数据同步过程中出现数据不一致。记录Row的话就可以保证主从同步不会存在SQL语意偏差的问题,同时Row类型的日志在做数据恢复的时候也比较容易,但是Row会导致binlog过大。

MySQL主从同步的几种模式:

  • 异步模式:
    在这种同步策略下,主库按照自己的流程处理完数据,会直接返回结果,不会等待主库和从库之间的数据同步。 优点:效率高。 缺点:Master节点挂掉之后,Slave节点会丢失数据。
  • 全同步模式: 主库会等待所有从库都执行完sql语句并ACK完成,才返回成功。 优点:有很好的数据一致性保障。 缺点:会造成数据操作延迟,降低了MySQL的吞吐量。
  • 半同步模式:主库会等待至少有一个从库把数据写入relay log并ACK完成,才成功返回结果。 半同步模式介于异步和全同步之间。

半同步的复制方案是在MySQL5.5开始引入的,普通的半同步复制方案步骤如下图:

  • Master节点写数据到Binlog,并且执行Sync操作。
  • Master发送数据给Slave节点,同时commit主库的事务。
  • 收到ACK后Master节点把数据返回给客户端。

这种数据提交模式叫:after_commit

MySQL高可用架构_第2张图片after_commit模式存在问题: 主库等待ACK时,事务已经commit,主库的其他事务可以读到commit的数据,这个时候如果Master崩溃,slave数据丢失,发生主从切换,会导致出现幻读。 为了解决这个问题MySQL5.7提出了新的半同步复制模式:after_sync

MySQL高可用架构_第3张图片 把主库的事务提交放到了ACK之后,避免了上述问题。 MySQL5.7还引入了enhanced multi-threaded slave(简称MTS)模式, 当slave配置slave_parallel_workers>0并且global.slave_parallel_type=‘LOGICAL_CLOCK’,可支持一个schema下,slave_parallel_workers个worker线程并发执行relay log中主库提交的事务,极大的提高了主从复制的效率。 MySQL5.7半同步功能可以通过rpl_semi_sync_master_wait_slave_count参数配置slave节点ACK的个数,认为主从同步完成。

基于MySQL主从同步数据越来越完善,效率越来越高,也就引出了第一种MySQL的高可用架构: 基于MySQL自身的主从同步方案,常用的一种部署架构是: 用户通过VIP访问Master和Slave节点,每个节点采用keepalved探活。配置主从关系,进行数据同步。

MySQL高可用架构_第4张图片

基于MHA的高可用架构: 部署一份MHA的Manager节点,在MySQL各个实例部署MHA Node节点。MHA可以实现秒级的故障自动转移。 当然MySQL节点之间的数据同步还要以来MySQL自身的数据同步方式。

MySQL高可用架构_第5张图片

MGR(MySQL Group Replication)模式: 感觉MySQL官方更看好MGR集群方案,但是目前我还不知道国内有哪一家公司在使用。 MGR集群是由所有的MySQL Server共同组成的,每个Server都有完整的副本数据,副本之间基于Row格式的日志和GTID来做副本之前的数据同步,采用Paxos算法实现数据的一致性保障。 MGR架构要比前面讲述的半同步和异步同步数据的方式要复杂,具体可以参照官网

MySQL高可用架构_第6张图片

总结

MySQL的高可用架构没有银弹,了解其原理,选择符合自己业务场景的部署架构就可以了。


作者:一行舟
链接:https://juejin.cn/post/6953789574489309192
来源:掘金
 

你可能感兴趣的:(分布式,数据库,java,mysql,redis)