如何分析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,使得这个过程更加平滑。
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注亿速云行业资讯频道,感谢您对亿速云的支持。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。