MySQL MGR

本文主要是介绍MySQL MGR，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、MGR简述

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

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

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

二、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 会把该节点踢出只读组，直到集群恢复后，它将自动更新到读组。

三、MGR 单主 + VIP

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协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。