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中几乎都考虑到了。如果说得简单点，主要有下面的几个场景需要考虑：
-
数据库主库宕机
-
数据库从库宕机
-
重启数据库主库
-
重启数据库从库
-
从库应用延迟
-
主从网络延迟
-
主库服务器宕机
-
从库服务器宕机
-
一主多从切换优先级
-
网络抖动的切换
-
手工主从切换
-
主节点IP调整
-
从节点IP调整
-
添加从节点
-
剔除从节点
-
网络抖动的预防
-
半同步插件对于MHA的影响
-
自定义MHA脚本
所以上面的方案多多少少都需要考虑，如果用下面的图来表示，就会大体有如下的一些红色警告。所以各个层面都会有可能存在问题和异常，如何尽可能不影响业务，保持业务科持续访问是重中之重。
举一个比较纠结的问题，如果MHA Manager节点到数据库主库的网络发生抖动，导致短时间不可访问，我们是希望这个过程是不会做灾难切换的，但是如果时间过长了，有2分钟或者3分钟都不可访问，这个时候是切还是不切呢。这个时候信息还是相对较少的，如果我们加入应用服务器这个角色，如果应用服务器是可访问的，那么就不切，如果应用访问受到影响，那还是切吧。而且根据我们的测试，在MHA 0.56和0.57里面还是有一些差别。测试了多套环境，测试了多个特性，结合起来才会发现对于MHA的考虑会更加全面，而换句话说，了解了原委，才能更好的掌握MHA，也才能看到更多的问题，来尝试定制它，使得它更加满足于当前的业务需求。
