|||
是什么原因不敢上MySQL MGR？
当我在群里说起MySQL MGR时，的确还有人不知道这是啥东东。有群友打趣，说这是：
我只能说，你们真的都是天才。言归正传。
MySQL MGR是MySQL组复制（Group Replication）的简称。
MGR是一种基于shared-nothing的，更方便实现数据一致性及高可用集群方案，此外它还支持故障自动检测及多节点并行写等特性。它由一组MySQL实例构成，每个实例都有一份完整的数据，实例间通过组通讯消息系统（GCS）交互通信协同。GCS可保证消息的原子性和消息在所有组成员的整体顺序一致。
MGR是MySQL自带的一个插件（plugin），可以灵活部署。
它要求组内每个MySQL实例都要基于ROW格式的binlog，并开启GTID。
MGR架构图如下所示，主要是APIs层、组件层、复制协议模块层和GCS API+Paxos引擎层构成。
事务从Server层经过MGR的APIs接口层分发到组件层，组件层去capture事务相关信息，然后经过复制协议层进行事务传输，最后经过GCS API+Paxos引擎层保证事务在各个节点数据最终一致性。
MGR具备以下技术特点：
MySQL MGR是在2015年就已经首次出现在MySQL 5.7版本中，至今已有多年，仍在不断成熟完善中。
一个反直觉的事实是，其实国内已有数个大中型银行上线MySQL MGR，当然了，现阶段还不是应用在非常核心的系统上。此外，亦有不少其他传统企业也在尝试使用MGR，更别说是互联网企业了，更是走在尝鲜的的前列。
哦，对了，Oracle公有云上的MySQL高可用版本据称也是用MGR架构的。
虽然知道MGR有这么多好处，而且也有大胆的同行在使用了，但还有不少人表示不放心，不太敢正式上线。
大家到底在担心什么呢？
从平时和大家交流的反馈来看，大家主要关切的有以下几点：
第一，需求不强烈
对于已经用惯了MySQL传统异步复制，以及后来的半同步复制、增强半同步复制，再配合其他第三方的高可用工具套件，已经可以满足绝大多数场景下的需求，所以大家并不急着用上MGR，还想继续观望。
第二，对新事物的恐惧
虽说MGR也发布数年了，但相对于上述提到的传统复制功能，其架构的复杂性，以及现存BUG的数量，都说明了MGR还是不够成熟，起码还没到足以让大家安心上线的阶段。
此外，由于MGR的架构复杂性，也使得大家在使用过程中遇到问题时，如果想要向官方报告，却苦于难以复现问题场景等客观因素，也打击了用户的信心。
我们从MySQL官方bug库搜到关于MGR的bug数量居然只有区区226个，很难说是不是因为复现太难导致无法报告。另外，这其中只有26个是active状态，个人认为这个数据是不太可信的。
我也查找了InnoDB和传统复制的bug数作为参照（active/all）：
第三，生态不成熟
上面我们说到，之所以大家还在坚守传统复制，是因为已有大量第三方工具打配合，就可以满足大部分业务需求了。
而可以和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在哪些方面做出改善。
合作电话：010-64087828
社区邮箱：greatsql@greatdb.com
