MySQL MGR看着很美,却又为什么不敢用?

简介: MySQL MGR看着很美,却又为什么不敢用?

0. 前言

1. 什么是MySQL MGR

当我在群里说起MySQL MGR时,的确还有人不知道这是啥东东。有群友打趣,说这是:

  • 美国人
  • 卖狗肉
  • 蒙古人

我只能说,你们真的都是天才。

image.png

言归正传。

MySQL MGR是MySQL组复制(Group Replication)的简称。

MGR是一种基于shared-nothing的,更方便实现数据一致性高可用集群方案,此外它还支持故障自动检测多节点并行写等特性。它由一组MySQL实例构成,每个实例都有一份完整的数据,实例间通过组通讯消息系统(GCS)交互通信协同。GCS可保证消息的原子性和消息在所有组成员的整体顺序一致

MGR是MySQL自带的一个插件(plugin),可以灵活部署。

它要求组内每个MySQL实例都要基于ROW格式的binlog,并开启GTID。

MGR架构图如下所示,主要是APIs层、组件层、复制协议模块层和GCS API+Paxos引擎层构成。

屏幕快照 2021-11-19 下午3.03.16.png

屏幕快照 2021-11-19 下午3.04.06.png

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

MGR具备以下技术特点:

  1. MGR是基于Paxos协议和原生复制的分布式集群,多数节点同意即可以通过事务提议(Proposed),实现数据一致性。
  2. 具备高可用、自动故障检测功能,可自动切换。
  3. 可弹性扩展,集群自动的新增和移除节点,集群最多接入9个节点。
  4. 有单主和多主模式。支持多节点写入,具备冲突检测机制,可以适应多种应用场景需求。

MySQL MGR是在2015年就已经首次出现在MySQL 5.7版本中,至今已有多年,仍在不断成熟完善中。

一个反直觉的事实是,其实国内已有数个大中型银行上线MySQL MGR,当然了,现阶段还不是应用在非常核心的系统上。此外,亦有不少其他传统企业也在尝试使用MGR,更别说是互联网企业了,更是走在尝鲜的的前列。

哦,对了,Oracle公有云上的MySQL高可用版本据称也是用MGR架构的。

2. 为什么不敢上MGR

虽然知道MGR有这么多好处,而且也有大胆的同行在使用了,但还有不少人表示不放心,不太敢正式上线。

大家到底在担心什么呢?

从平时和大家交流的反馈来看,大家主要关切的有以下几点:

第一,需求不强烈

对于已经用惯了MySQL传统异步复制,以及后来的半同步复制、增强半同步复制,再配合其他第三方的高可用工具套件,已经可以满足绝大多数场景下的需求,所以大家并不急着用上MGR,还想继续观望。

第二,对新事物的恐惧

虽说MGR也发布数年了,但相对于上述提到的传统复制功能,其架构的复杂性,以及现存BUG的数量,都说明了MGR还是不够成熟,起码还没到足以让大家安心上线的阶段。

此外,由于MGR的架构复杂性,也使得大家在使用过程中遇到问题时,如果想要向官方报告,却苦于难以复现问题场景等客观因素,也打击了用户的信心。

我们从MySQL官方bug库搜到关于MGR的bug数量居然只有区区226个,很难说是不是因为复现太难导致无法报告。另外,这其中只有26个是active状态,个人认为这个数据是不太可信的。

我也查找了InnoDB和传统复制的bug数作为参照(active/all):

  • InnoDB:475/2925
  • Replication:360/2584

第三,生态不成熟

上面我们说到,之所以大家还在坚守传统复制,是因为已有大量第三方工具打配合,就可以满足大部分业务需求了。

而可以和MGR配合的第三方工具生态还不够完善,除了MySQL官方的InnoDB Cluster套件(MySQL Router + MySQL Shell + MGR)之外,几乎没有随手拿来就能用于构建整套高可用架构的解决方案。想要线上更大规模使用MGR,还需要有足够的生态建设才行。

第四,MGR还不够可靠

从各方面多个渠道反馈的情况来看,大家在测试及使用MGR的过程中,或多或少都出现异常宕机、事务挂起、节点异常退出、性能抖动等大大小小的问题。MGR现阶段给大家的感觉,还是不那么可靠、令人放心。

不过我们参考并行复制的进程,也是一开始从database级别并行,再到事务级别并行,现在又支持WRITESET并行,都有个先从0到1,再从1到99的过程,这些都是必经之路,MGR还有一段路需要走。

写在后面

任何新事物被大众所接受都要有个过程,大多数人也会习惯性批判新事物,因为能看懂的毕竟还是少数。

是时候再温习下MySQL官方的产品计划路线图了,以此加强对MGR的信心:


此外,最近业界发布的GreatSQL也给了我们更多上线(起码进一步试用)MGR的信心。GreatSQL是源于Percona server的分支版本,除了Percona server已有的稳定可靠、高效、管理更方便等优势外,特别是进一步提升了MGR(MySQL Group Replication)的性能及可靠性,以及众多bug修复。

还有,我也想趁这个机会了解大家在使用MGR过程中遇到哪些问题、痛点,或者希望MGR在哪些方面做出改善。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
机器学习/深度学习 并行计算 Shell
docker 获取Nvidia 镜像 | cuda |cudnn
本文分享如何使用docker获取Nvidia 镜像,包括cuda10、cuda11等不同版本,cudnn7、cudnn8等,快速搭建深度学习环境。
7572 0
|
存储 人工智能 运维
重磅!阿里云可观测产品家族全新升级,AI +数据双驱动,打造全栈可观测体系
近日,阿里云可观测产品家族正式发布云监控 2.0,隶属产品日志服务 SLS、云监控 CMS、应用实时监控服务 ARMS 迎来重磅升级。
1316 95
|
存储 网络协议 Linux
三次握手时,客户端发送的 SYN 报文为什么会被丢弃?
三次握手时,客户端发送的 SYN 报文为什么会被丢弃?
364 12
|
SQL 关系型数据库 MySQL
mysql密码的初始化,修改与重置
【8月更文挑战第16天】在 MySQL 中,可通过特定步骤初始化、修改或重置密码: 1. **初始化密码**:适合首次安装或遗忘 root 密码。需先停用 MySQL 服务,以特殊模式启动(跳过权限表),登录后更新 root 用户密码,并重启服务。 2. **修改密码**:直接使用 `ALTER USER` SQL 语句或通过客户端工具如 MySQL Workbench 修改现有用户的密码。 3. **重置密码**:若遗忘密码且初始化方法不可行,则需停用服务、修改配置文件以允许无密码启动 MySQL,登录后更改密码,并恢复正常配置重启服务。
4105 2
|
机器学习/深度学习 算法 物联网
大模型进阶微调篇(一):以定制化3B模型为例,各种微调方法对比-选LoRA还是PPO,所需显存内存资源为多少?
本文介绍了两种大模型微调方法——LoRA(低秩适应)和PPO(近端策略优化)。LoRA通过引入低秩矩阵微调部分权重,适合资源受限环境,具有资源节省和训练速度快的优势,适用于监督学习和简单交互场景。PPO基于策略优化,适合需要用户交互反馈的场景,能够适应复杂反馈并动态调整策略,适用于强化学习和复杂用户交互。文章还对比了两者的资源消耗和适用数据规模,帮助读者根据具体需求选择最合适的微调策略。
4019 5
|
Java 数据库连接 网络安全
Nacos报错问题之集群节点间的健康检查超时异常如何解决
Nacos是一个开源的、易于部署的动态服务发现、配置管理和服务管理平台,旨在帮助微服务架构下的应用进行快速配置更新和服务治理;在实际运用中,用户可能会遇到各种报错,本合集将常见的Nacos报错问题进行归纳和解答,以便使用者能够快速定位和解决这些问题。
1468 4
|
SQL 关系型数据库 MySQL
删库,误清数据怎么办?MySQL数据恢复指南
相信很多同学在面对线上数据库时都畏手畏脚,即使这样都难免手滑,一不小心手一抖就将数据或者是表,库删除。当然一些注重规范的公司,不会给开发人员删除表或者是库的权限,但误删数据是常有的事,那么这种情况发生,我们改怎么办呢?跑路?哈哈,当然删库跑路是句玩笑话,本文就为大家介绍一些数据误删除恢复的办法。
3874 0
|
网络协议 Linux
Linux内核协议栈丢弃SYN报文的主要场景剖析
在排查网络问题的时候,经常会遇见TCP连接建立不成功的场景。如果能获取到两端抓包,两端抓包看起来如下:客户端在一直按照指数退避重传TCP SYN (因为首包没有获取到RTT及RTO,会在1, 2, 4, 8秒... 重传,直到完成net.ipv4.tcp_syn_retries次重传);服务器端能看到TCP SYN报文已经到达网卡,但是TCP协议栈没有任何回包。
14819 0