MySQL高可用方案MHAJedi是一个非常成熟的实现。对于数据的切换，其实MGR也可以很好的完成，也就是说数据层面的角色切换已经刻意的顺利的完成了，但是接入IP处理的空间还是很大的，MHA提供很多可选空间支持。常见的组合有：MHA+VIPMHA+keepaliveMHA+Zookeeper当然MHA+VIP是非常成熟经典的方案。一般来说，有如下类似的架构方法，假设架构模型是一主二从。应用接入时，提供的IP信息以绑定的VIP地址为准。VIP可以根据节点的数据状态在不同节点间漂移，实现无缝切换的高可用。MHAManager是一个核心调度器，它可以调度多套环境。当然MHAManager本身也是有单点的，所以会考虑两套MHAManager节点冗余。设置环境，两个MHAManager节点，每个节点分为50个节点，如果Manager节点出现故障，可以交给Manager2顺利接管。对于应用，统一通过VIP方式接入。如果在此基础上再考虑中间件方案，数据访问策略会更加复杂。对于这样一个基础方案，如果从多个维度下钻，会发现需要注意的地方很多，所以问题无处不在，好在MHA中几乎都考虑到了。简单来说，主要有以下几种场景需要考虑：主库宕机，从库宕机，重启数据库，重启主库，重启从库。宕机、一主多从、切换优先级、网络抖动切换、手动主从切换、主节点IP调整、从节点IP调整、添加从节点、消除从节点网络抖动预防、半同步外挂影响MHA，自定义MHA脚本，所以上面的方案或多或少需要考虑一下。如果用下图来表示，会有如下一些红色警告。因此，各个层面都可能出现问题和异常。如何尽可能不影响业务，保持业务部门持续访问是重中之重。举个比较纠结的问题，如果MHAManager节点和主库数据库之间的网络出现波动，导致短时间无法访问，我们希望这个过程不要进行灾难切换，但是如果时间过长，就会出现2分钟或以上3分钟未接入，此时是否切。目前信息还比较少。如果我们加上应用服务器的角色，如果应用服务器是可以访问的，那么就不要砍了。如果应用程序访问受到影响，则将其切断。而且根据我们的测试，MHA0.56和0.57之间还是有一些区别的。在测试多套环境，测试多个特性后，我们会发现组合起来对MHA的考虑会更全面。也就是说，只有了解原委，才能更好地掌握MHA，看到更多的问题。让我们尝试对其进行定制，使其更符合当前的业务需求。
