Orchestrator初试

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

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

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

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

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

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

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

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

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

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

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