MYSQL 为什么MGR OR INNODB CLUSTER 没有成为主流的MYSQL 高可用方式

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共1100人左右 1 + 2 + 3）新人会进入3群

提到这个问题本身，很多年前很多人都看好MYSQL的 MGR ，mysql group replicaiton，到后来演进的innodb cluster 的解决方案，但是截至到现在，MYSQL 8.1 的版本历经了超过5年的发展，还是没有发展起来，为什么，一个看上去都很好的先进的解决方案，他不行，或者从来就没有，行过。

从浅层次来看，主要有以下的一些问题，导致

1  复制的延迟，MYSQL的高可用方式的变换属于换汤，但MYSQL的复制方式从来不换，这属于药不换，换汤不换药必然是没有什么好的结果，复制延迟的问题，一直是其他数据库 DISS MYSQL的核心点，BINLOG 并不美，上到商业数据库ORACLE SQL SERVER ，在到现在火热的 POSTGRESQL ，都没有使用 MYSQL 的这套数据复制的方案，是MYSQL 太先进了，还是一直在错误的路线上，高速行驶，不撞南墙，死不休，针对一些开发场景，必须有大事务，那么MYSQL 在复制方面，如同失控的汽车，哪里能同步上，还是看命。

虽然我们一次次的看到MYSQL 在复制方面的努力，尽量消除逻辑顺序，让无关顺序的事务能同步进行复制，但是瘸子，在先进，他还是一个瘸子。根源设计架构的毛病，是娘胎里面带的，这个......

2  MYSQL 在MGR中的多主的功能，MYSQL的多主在基本上没有什么人用的 MGR的基础上衍生而来，这属于一个非常好的功能，但是如同，三里屯里面的穿的非常 “清爽” 的小姐姐们，你看看就好，你这辈子都别想碰。这个功能属于，跑还没有会，在瘸子的基础上，还让瘸子连短跑，在高并发和事务大的情况下，这个属于让瘸子去死的一个好方法。这也就印证了一句话，理想是远大的，但实现不实现的了，那就说不准了，一个说不准的功能，抱歉，用不了

3  MYSQL 集群的PAXOS 的协议，这更是一个坑，基于MYSQL本身的复制的结构，和对于大事务的惧怕，PAXOS 协议的 MYSQL MGR , INNODB CLUSTER ，更是一个看上去很美的，在夏天待不住的 冰激凌。我们也曾经试过MGR ，一开始很好，很美，我们雀跃欢呼，终于可以和MHA ，或者一众与MYSQL 复制相关的 “破” 高可用插件说再见了，可很快我们就 被 “撞击了”，注意用词，不是打击，是撞击，不是每个空间都能是无菌的，MYSQL MGR 如同在温室里面的婴儿，只能在暖箱里面呆着，而只要稍微的拨弄一下网络的稳定性，或者某个主机的硬件有一点的性能问题，他里面 散给你看，集群经常直接就散掉了，并且你无法快速的介入，只能看见温室里面的婴儿，没有了呼吸。

4  更专业人士的意见，爱可生在MYSQL 业内是最早获得ORACLE 对于MYSQL 的认可的机构，同时也是自主研发了多种基于MYSQL的，自主金融级别的产品的公司，以及大家耳熟能详的  DBLE ，SQLE ，等开源的MYSQL 产品，爱可生的黄总也给出了一些意见，基于数据链路和控制链路没有分离的设计，走了相同的一致性协议，在设计的方面有待考量。

感谢黄总，给出了更专业的提点。

5  网络带宽的要求与自动故障切换的问题，这点也要来说说，在当时分布式数据库还没有太兴起，MYSQL MGR 本身也让我们都与网络的带宽的需求有了更多的认识，MGR 是对于网络的带宽有了一定的要求，而不是随便搞搞就好，网络带宽成为MGR 稳定性重要的一环，而网络的稳定性更是第二点 PAXOS 协议使然的 MGR 强烈的要求，所以至少3个节点，3个节点要求网络互通，以及信息传递的及时性，导致 MGR 本身很难飞到我们每个百姓家，他终究是象牙塔里面的产物。

6  自动切换与中间件的问题，基于MYSQL的战略，MYSQL的myrouter一致是我们的mysql 的官方中间件产品，通过他我们才能在MYSQL MGR 进行切换的情况下，我们让应用程序快速的导入到 “新主”，在这样的情况下我们才能正常的使用MGR 或者说 MYSQL INNODB CLUSTER，但是，MYROUTER 本身也有一些问题，如性能方面的开销，高并发负载极致场景下的稳定性的问题，同时还有一致性的问题，在分发查询请求的情况下，是否能判断哪个节点复杂压力大，而尽量少的转发访问的请求。以及一些强一致场景下的需求等等。

最后一点，是压倒MGR的稻草，就是目前的很多机构，如爱可生本身在金融企业方面有比较完善的商业性的高可用和金融等级的替换方式的高可用，判断，切换，后备MYSQL 的方式，让整体的方案在金融的领域更能被接受，从方案的评定上，至少是行得通稳定的。同时在非金融的领域，一些企业还是持续使用稳定的 INNODB REPLICATION 或者 MHA 或类似的方案等，也让MGR 没有太多的市场。最终，MGR 如同姥姥不疼，舅舅不爱的角色，在MYSQL 的世界中，持续的 “试戏”，但连配角都不曾上演。

由于这个话题，在1 ，2 群里展开了激烈的讨论，这里就不详述了。

借用在群里我们讨论此问题时，某个同学的话，MYSQL MGR ，在给他5年。