最近看了下MySQL Group Replication的内容，因为发布的时间不是很长，可以算是一个新鲜玩意，而且因为它特有的意义，这个特性显得更加意味深长。
我接触Oracle的时间要长一些，所以很多时候都喜欢带着对比的眼光来看，单着自己尝试着用了下这个特性，感觉一下子让我找到了当年学习Oracle 10g RAC时的感觉，里面还是有一些小问题，而且还不少，眼巴巴的看着报错，但是日志又很有限，查阅资料，竟然不是bug就是找不到一些相关的信息，所以有时候有种信息孤岛的感觉。
官网的资料自己也看了好几遍，在自己在电脑环境中也模拟了不下十次，每次感觉都是差一点，有一些让人感觉不大满意的地方，我觉得在这方面的付出可真不比Oracle少，而且我也知道这个新特性要达到成熟到普及，还需要时日。这个过程总是让人难忘而且艰辛。
首先这个特性，使得MySQL和Oracle体量更加接近，看看下载的二进制包就让人手里一抖，压塑包600多M,但是解压后竟然有差不多2.6G.
# du -sh ./*
2.6G ./mysql-5.7.17-linux-glibc2.5-x86_64
625M ./mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz
如果仔细往下看，就会发现里面group replication的部分占用的空间确实不少。
我想下面的这个图，如果要看group replication都要说上一段，各类博客中都有自然引用到，原来来自于官网的解读。

从原生的Replication过渡到插件式的半同步，再到Group Replication，真是一个很大的进步，高可用方案随着这个技术的成熟相比也会逐渐成为一种趋势，从Galera到后面Percona包装的PXC,从Group replication的角度再回头来看，竟然发现是如此相似。Galera的作者都是一批20多年实战经验的老鸟，在技术成熟度方面肯定完全不逊于官方。所以选择哪一个或者哪一个更成熟，到时候会是摆在MySQL DBA面前的一个艰难的选择。
然后再来一张图。MySQL 插件的结构图。

MySQL的这个高可用方案是一个share nothing的架构，这样也就使得整个架构是一个强一致性的设计方式，自然会用到组播的方式。
Oracle中搭建RAC需要一个集群软件，早期是可选第三方，后来统一为Oracle专供，也就是后来所说的Grid Infrastrue,不光整合力集群软件，ASM的部分也整合进去了，有点强拆的感觉。MGR的模式目前是推荐单主的形式，即读写分离的方式，也可以做到多主。
MySQL Group Replication中的这个部分是由Corosync来实现的，corosync的由来是源于一个Openais的项目，可以实现HA心跳信息传输的功能，是众多实现HA集群软件中之一，在MGR早起的实验室版本还需要特意关注这部分的信息，特意的设定和配置使得集群环境能够稳步运行，MGR也是包含了绑定corosync的接口，这个接口实际上是corosync到clientAPI的一个隐式映射。
由此我也看到了几个不错的解决方案，

corosync+pacemaker+mysql+drbd 实现mysql的高可用，还有搭建Group Replication很有想法的一个实践，就是先配置gtid,然后切换到group replication，使得这个过程更加平滑。