mha mysql 中国用的多吗_MySQL高可用方案MHA的一些总结和思考

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

数据库主库宕机数据库从库宕机重启数据库主库重启数据库从库从库应用延迟主从网络延迟主库服务器宕机从库服务器宕机一主多从切换优先级网络抖动的切换手工主从切换主节点IP调整从节点IP调整添加从节点剔除从节点网络抖动的预防半同步插件对于MHA的影响自定义MHA脚本

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

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