MySQL MGR

一、MGR简述

在 2016 年 9 月的 Oracle Openworld 上,MySQL 官方提出了 MySQL InnoDB
Cluster 的概念,并将其定为 MySQL 未来的发展目标。其核心就是用 MySQL 数据
库和原生工具构建出一个全栈高可用 MySQL 集群系统,用来支撑大规模 MySQL
集群的使用,特别是云上的使用。其 Group Replication 是 MySQL InnoDB Cluster
这个及具潜力产品中的核心组件。


Mysql 官方推出的集群架构,主要由 3 个模块组成:

  1. 支持 Group Replication 功能的 Mysql Server,主要功能在于实现了组内通信、故障转移和故障恢复;
  2. Mysql-Shell:实现快速部署,主要提供了一套 AdminAPI,可以自动化配置 Group Replication。
  3. Mysql-Router:内置读写分离,负载均衡。自动根据 Mysql InnoDB Cluster中的 metadata。

二、MGR 单主 + VIP 

1、MGR

MGR (MySQL Group Replication)是MySQL自带的一个插件,可以灵活部署。MySQL MGR集群是多个MySQL Server节点共同组成的分布式集群,每个Server都有完整的副本,它是基于ROW格式的二进制日志文件和GTID特性。架构主要是APIs层、组件层、复制协议模块层和GCS API+Paxos引擎层构成。

应用发来的事务从MySQL Server经过MGR的APIs接口层分发到组件层,组件层去capture事务相关信息,然后经过复制协议层进行事务传输,最后经过GCS API+Paxos引擎层保证事务在各个节点数据最终一致性。这是事务进入MGR层内部处理过程。

MGR由若干个节点共同组成一个复制组,一个事务的提交,必须经过组内大多数节点(N / 2 + 1)决议并通过,才能得以提交。如上图所示,由3个节点组成一个复制组,Consensus层为一致性协议层,在事务提交过程中,发生组间通讯,由2个节点决议(certify)通过这个事务,事务才能够最终得以提交并响应。
 
引入组复制,主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体),实现了分布式下数据的最终一致性,提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案,给我们实现多活方案带来了希望。

2、MGR架构

MySQL MGR(MySQL Group Replication)是一个高可用性和容错性的解决方案,旨在提供数据冗余和故障转移。当使用三个节点的MGR集群时,如果宕掉了两个节点,集群的行为将取决于节点的宕机方式。

  1. 正常关闭
    如果两个节点是正常关闭的(例如,通过执行STOP GROUP_REPLICATION命令),它们会向MGR集群发送退出信号。在这种情况下,这两个节点将被视为正常退出,而剩下的一个节点将被提升为Primary角色,并继续处理读写操作。此时,集群失去了冗余性,因为只有一个节点在运行。当其他节点再次启动并加入集群后,集群将恢复其完整性和高可用性。

  2. 异常宕机
    如果两个节点由于网络故障、mysqld进程崩溃或被误杀等原因异常宕机,这些节点将被标记为UNREACHABLE状态。在这种情况下,MGR会等待group_replication_member_expel_timeout时长(默认为10秒),之后这些节点将被正式从集群中剔除。如果此时超过半数的节点(在这个例子中是两个节点)处于UNREACHABLE状态,整个集群将被标记为不可用,无法提供读写服务。在这种情况下,需要重启剩余节点的MGR服务以恢复集群的正常运行。

在MySQL MGR的三节点集群中,如果宕掉了两个节点,集群的行为将取决于节点的宕机方式。如果节点是正常关闭的,剩下的节点将继续运行并提供服务,但失去了冗余性。如果节点是异常宕机的,且超过半数的节点不可达,整个集群将变得不可用,直到剩余的节点被重启并重新加入集群。为了避免这种情况,建议在设计MGR集群时考虑使用更多的节点,以增加冗余性和容错能力。

三、ProxySQL

 ProxySQL 是一款轻量级中间件,它支持 Query 路由,支持动态指定某个 SQL 进行缓存,并且可以动态加载配置(无需重启 ProxySQL 服务)、另外可 以配合 MGR 完成故障切换和读写分离。

工作原理:它通过 6032 端口代理 MySQL 服务,使用 mysql_users 配置数据 库用户,使用 mysql_group_replication_hostgroups 定义 mgr 集群的写组、备写组、 读组、离线组,使用 runtime_mysql_servers 定义数据源。服务启动后,代理服务 把 MGR 集群状态更新到 runtime 层。使用 mysql_query_rules 配置读写分离规则 (用户自定义)后,根据 server 表的数据库状态,分别把只读请求路由到读组的 集群节点(即 MGR secondary 节点),事务和写请求路由到写组的集群节点(即 MGR Primary 节点)。当 Primary 节点故障时,ProxySQL 会实时探测集群状态变化,把新 Primary 节点更新到写组,这样新的请求依然可以正确访问到写组的数 据库节点。如果 MGR 的 Secondary 节点故障,ProxySQL 会把该节点踢出只读组, 直到集群恢复后,它将自动更新到读组。