如何分析MySQLGroupReplication

如何分析MySQL Group Replication，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：申请域名、网页空间、营销软件、网站建设、阳江网站维护、网站推广。

最近看了下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到client API的一个隐式映射。
   由此我也看到了几个不错的解决方案，

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

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注创新互联行业资讯频道，感谢您对创新互联的支持。