MySQL高可用方案中MHA绝地是一个相当成熟的实现。对于数据的切换，其实MGR也能很好的完成，也就是说，数据层面的角色切换已经刻意很平滑的做好了，但是对于访问IP的处理，还是有很大的空间，MHA提供了很多可选的空间来支持。

常见的组合方式有：

MHA+VIP

MHA+keepalive

MHA+Zookeeper

当然MHA+VIP是一种很成熟和经典的方案了。

一般来说都有以下类似的架构方式，假设架构模式为一主两从。对于应用访问来说，提供的IP信息就依据绑定的VIP地址为准。VIP可以根据节点的数据状态在不同节点间漂移，达到无缝切换的高可用。

MHA Manager是一个核心的调度器，有了它可以调度多套环境，当然MHA Manager自身也有单点，所以会考虑两套MHA Manager节点来做冗余，实际上是做交叉互备，比如有100套环境，两个MHA Manager节点，那就每个分50个节点，如果Manager节点出现故障，可以很顺利的交接给Manager2来接管。

对于应用来说，就是统一通过VIP的方式来访问。如果是在这个基础上考虑中间件的方案，则数据访问的策略会更加复杂一些。

对于这样的一个基本方案，如果从多个维度来下钻会发现有很多需要注意的地方，所以问题无处不在，可喜的是在MHA中几乎都考虑到了。如果说得简单点，主要有下面的几个场景需要考虑：

1. 数据库主库宕机

2. 数据库从库宕机

3. 重启数据库主库

4. 重启数据库从库

5. 从库应用延迟

6. 主从网络延迟

7. 主库服务器宕机

8. 从库服务器宕机

9. 一主多从切换优先级

10. 网络抖动的切换

11. 手工主从切换

12. 主节点IP调整

13. 从节点IP调整

14. 添加从节点

15. 剔除从节点

16. 网络抖动的预防

17. 半同步插件对于MHA的影响

18. 自定义MHA脚本

    所以上面的方案多多少少都需要考虑，如果用下面的图来表示，就会大体有如下的一些红色警告。所以各个层面都会有可能存在问题和异常，如何尽可能不影响业务，保持业务科持续访问是重中之重。

举一个比较纠结的问题，如果MHA Manager节点到数据库主库的网络发生抖动，导致短时间不可访问，我们是希望这个过程是不会做灾难切换的，但是如果时间过长了，有2分钟或者3分钟都不可访问，这个时候是切还是不切呢。这个时候信息还是相对较少的，如果我们加入应用服务器这个角色，如果应用服务器是可访问的，那么就不切，如果应用访问受到影响，那还是切吧。而且根据我们的测试，在MHA 0.56和0.57里面还是有一些差别。测试了多套环境，测试了多个特性，结合起来才会发现对于MHA的考虑会更加全面，而换句话说，了解了原委，才能更好的掌握MHA，也才能看到更多的问题，来尝试定制它，使得它更加满足于当前的业务需求。