MHA正确玩法，能给解决大部分切换问题

一、vip切换

切换 lvs/f5 而不是本地vip。解决避免本地vip会绑定多个MySQL的情况。

二、配置文件生产

每次在线切换/离线切换配置文件自动生成。解决配置文件生成不准造成的切换失败。

三、MHA只负责切换

单独监控程序负责监控。监控程序与MHA（切换程序）剥离开。解决大规模MHA 开销庞大。MHA的探测也不够灵活。

四、MHA 无状态

mha-manager 是无进程不启动。切换的时候通过tcp http协议调度任何一台MHA 机器，就可以完成切换操作。

MHA则是一个无状态 的服务。解决因为MHA 服务宕机 导致无法切换。

五、总结

整体链路：

在线切换：通知MHA服务，生产配置文件，MHA进行切换 切换上层VIP。

注：切换VIP的操作是一个原子性的操作

故障切换：由监控程序 监控到异常 放到队列，检测异常程序2次检测，确认。生产配置文件，MHA进行切换。切换 上层VIP。

该架构好处： 

1、解决了MHA 配置文件与实际情况不准的情况。

2、解决了MHA组建异常 导致无法切换的问题。

3、减少了误切换，探测更准确。

4、采用切换上层VIP的模式 比本地VIP模式好处 可能会出现一个VIP绑定多个MySQL的情况，导致数据写错。

缺点：

需要改MHA的源码。技术实现有要求。

有人实现了这套架构嘛 答案是有的。。。。

今天看  TiDB的大佬文章 https://www.jianshu.com/p/cc6746ac4fc2 

主要是现在主流的高可用架构应该是 Orchestrator 。

就随便说说吧