Orchestrator初试

这是学习笔记的第 2067 篇文章

对于MySQL高可用方向,其实有很多的可选方案。

非常经典的方案就是MHA了,可能很多同学会说这个方案有些过时了,确实有一些时代烙印,这个方案推出10多年了,它推出时的年代是没有现在这种社区繁荣的,在高可用切换过程中的数据丢失情况还是有很大的风险的,抛开这些我们用一种更独立的眼光来看待,MHA确实有很多硬伤,但是仍然不失为一种经典的高可用方案,如果查看它的源码就会发现,里面的逻辑校验的粒度是下了很大的功夫的。

当然现在来看,我们是需要对高可用方案做下升级的,这里面有几个是MHA做得不够好的地方,比如MHA是偏底层技术的实现方式,它缺少一整套的工具集和补充方案,另外MHA要做定制的难度比较大,因为是基于Perl开发的,而Perl的时代烙印更加明显,已然和主流的开发语言存在差异。

Orchestrator就是这样一个很不错的补充,它提供了基于平台化页面的处理方式,如果要做多套的高可用环境管理,可以很方便的使用它自动探测生成的拓扑结构来,而且对于故障切换也有自己的一套,难能可贵的是,它提供了丰富的接口功能,也就意味着你想要做一些改变是鼓励的,开发基于go语言,而且它基于RAFT协议完善了高可用管理,从各个角度来看,都算是一个新贵了。

我做了下基础的测试,绑定了一两台公有云服务器,可以基于配置中心关联多套环境,整个过程是不需要任何前端页面开发的。

我配置了一主多从的环境,能够很方便的建立复制拓扑关系。

拓扑关系的页面类似这样,如果是多套环境可以对相关的参数做一些相应的变更。

对于数据延迟,参数的管理都可以做到细粒度的管理。

比如里面一个很不错的功能是可以实现相关参数的平台化管理,并且有相关的标签提示,还是很方便的。

后续如果要做细致的测试,switchover和failover就是必测的经典场景了,在此先做下普及,后续也会把这块的内容细致的整理出来。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2019-08-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券