MySQL Innodb Cluster 高可用推广“失败” 了？

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2680人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群380+，8群，准备9群)

好久没有说MySQL的问题了，最近一件事情让我对MySQL的InnoDB Cluster，或者叫组复制技术，没有推起来有了新的感悟。

用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊

说起MySQL的组复制，那是好多年前的事情，我依稀记得当时宋老师（宋利兵）还在甲骨文负责这块的工作，当时是叶老师和吴老师（如果不知道我说这二位是谁，说明你不是一个MySQL老炮），有一期吴老师请来宋老师给大家科普了什么是 mysql group replication,想想应该是2018年的事情了，当时我用的时候还是MySQL 5.7盛行的年代，MySQL8用的人还比较少，我还做了练习并将这个gourp replication用到当时公司的测试系统。

但最后我们也没有敢将这个技术，推广起来，原因是心塞的group replication 在网络情况不好，或大事务的情况下，崩溃过几次，且修复不了，基于这个原因后续也就停止的研究这个部分，还是在使用主从的模式。

这一晃2024年了，group replicaiton 还是没推起来，宋老师去了阿里云，叶老师服务了国产数据库，吴老师也干起了自己的公司， MySQL 呀。对说主题，为什么MySQL innodb cluster 没干起来。今天我从另一个角度来说说，或者剖析这个innodb cluster/group replication为什么没干起来说起。

一句话，MySQL Innodb cluster是一场彻头彻尾的开源数据库产品力上典型的失败案例。

以下从几个方面来说明：

1 MySQL的启动Innodb cluster的动机是什么！

MySQL 启动 group replication的主要动机是为了ORACLE Cloud的MySQL 云服务或私有云系列而准备的，或者为MySQL Enterprise 版本服务器的，对于开源的部分MySQL或许希望使用者成为小白鼠或者实验者的想法可能更多。 现在大家都非常清楚甲骨文在云上发力，且Oracle已经作为世界4大云厂商，数据库的盈利对他来说未来越来越不重要，而云上的环境中如果使用MySQL要求会更严苛，他们需要一套坚固的，在云环境中可以完美实现高可用切换且使用完善的高可用协议实现的产品。产品都需要进行打造，那么MySQL开源的部分就是他们要用户去尝试，去找问题，去反馈，更多的用户反馈更有利于产品的发展，而MySQL的ORACLE 云并不是每个用户都能用到，尤其中国的客户。所以推出这样的产品，让更多的客户用到，并且为企业版私有云部署提供标准化统一的方案，这才是甲骨文对于MySQL Innodb cluster部分的最大目的。

2 Innodb cluster可见成本不友好

MySQL流行的主要原因是成本低，（当然这个部分我不是太认可，只是部分人认为他成本低，实际上不低）。一般我们做MySQL都是主从的方式，而innodb cluster 在使用中要求的是至少3台主机，这无形中提高了MySQL使用的成本。我们来算一笔账。

如果我们有10套MySQL的数据库，如果是主从的方式那么我仅仅是需要20台主机，而如果使用了innodb cluster 的方式，我们且不说你的mysql router 或者proxysql的代理需求，仅仅说你的集群方式必须3台，那么你将多出来10台的主机。

10台的主机的钱谁来出，甲骨文给你出吗？ 公司会问到你，原来的主从模式挺好，为什要用innodb cluster的模式来做高可用。大部分使用MySQL的企业，都还是比较在乎成本的，小企业在乎，大企业也在乎，MySQL的数据量越多，越在乎成本。

这里我们还没有提到，对网络要求的严苛，我们可能还要更换交换机满足大量MySQL数据库产品的上线应对的网络流量的问题，和网络稳定性的问题，至少需要冗余一套网络设备防止数据库解体。

3 Innodb cluster的要求高，导致收益不匹配

这句话从何而来，MySQL我是从5.1开始用起来的，当初MySQL数据库的目的是为了小型应用而服务的，最早的初衷也不是为大型应用而服务的。基于MySQL的应用在早期都是小型的应用，早期数据库的类型还不丰富，基于阿里集团更换oracle数据库为目的，选择了MySQL后才有了MySQL在中国的辉煌。应运而生了分库分表的组件等等，Innodb cluster 的出现对于一个管理小型应用的数据库产品，拔高了他在高可用上的要求。

1  至少3台服务器，且三台服务器的配置需要相同 

2  网络环境的要求，相对于之前的复制协议，有了更严苛的稳定性要求，同时带宽的要求也变得更加重要。 

3  更复杂的参数配置，NTP时间维度的要求 

4  事务大小的变得更加敏感

MySQL本来就是一个灵活性较高的产品，而在使用innodb cluster后整体的要求变高了，可收益没有提高，单体的MySQL依然无法存储更高数据量的表，相对于其他的数据库产品，可能我2-3套能Hold住的情况，MySQL需要更多的数量来完成这些项目的建立，收益非常的不匹配。

尤其现在有了PostgreSQL,这让MySQL的性价比更低了。

4 技术的硬伤与缺陷，与人设不符

MySQL 的复制机制（基于二进制日志）本身就存在一定的延迟。虽然 Group Replication 在一定程度上通过并行复制等技术缓解了延迟问题，但在高并发、大事务的场景下，延迟仍然可能比较明显。

同时这和MySQL高并发，高吞吐的人设与innodb cluster 本身产生了冲突，更高的并发导致冲突检测和解决问题的复杂性。在高并发场景下，冲突可能会更加频繁，影响性能。 本身是为了提高性能，最后成了拖后腿的。组复制在处理大事务时可能存在一些限制，例如可能导致集群性能下降或阻塞。这使得一些需要处理大事务的应用不太适合使用 InnoDB Cluster。

5 早期的版本稳定性和匆忙推出产品，导致口碑差

1 脑裂的问题 早期版本的 Group Replication 协议在处理网络分区等故障时不够健壮，更容易出现脑裂问题。虽然后续版本通过改进协议和引入 Paxos 协议等方式大大降低了脑裂的风险，但口碑已经形成了，这就不太容易改变了。

2 成员管理问题 早期版本在处理成员加入和退出集群时可能存在一些问题，例如加入速度慢、退出不干净等。这些问题可能导致集群短暂的不可用或性能下降。

3 错误处理和日志信息 早期版本在出现错误时，提供的错误信息不够清晰，难以定位问题，这也是早期使用吐槽的地方，日志信息不详细，出现问题根本不知道哪里出现了问题。

平心而论，当前的MySQL的innodb cluster 已经走向的成熟，其实现在使用作为一个稳定的高可用形式，还是不错的，可既定的影响已经产生，人的观念很难改变，同时还存在一个问题，innodb replicaiton的方式也不错，相对innodb cluster更加的皮实，且学习的知识也不是太多。

最重要的灵一个问题是，当今MySQL的高速发展期已经过去了，现在数据库对于MySQL来说是存量市场，新兴的市场被 OceanBase,Tidb,PostgreSQL,等商业产品和开源产品逐渐霸占，更多的人不是不想研究，是没有动力研究。

MySQL相关文章