如何使用MySQL高可用解决方案MHA

MHA Jedi是MySQL高可用解决方案中相当成熟的实现。事实上，MGR也可以很好地完成数据切换。也就是说，角色切换数据层面已经刻意、顺利地做到了，但是对于接入IP的处理还有很大的空间，MHA提供了很多Optional的空间来支持。

常见的组合有：

MHA+VIP

MHA+keepalive

MHA+Zookeeper

当然，MHA+VIP是非常成熟、经典的方案。

一般来说，有类似的架构如下，假设架构模式为一主二从，对于应用程序的访问，IP信息提供的内容以绑定的VIP地址为准。 VIP可以根据节点的数据状态在不同节点之间漂移，实现高可用的无缝切换。

MHA Manager 是一个核心调度程序。有了它，可以安排多组环境。当然，MHA Manager本身也有单点，所以会考虑两组MHA Manager节点进行冗余。其实就是交叉替换，比如有100个环境，有2个MHA Manager节点，那么每个节点就划分为50个节点。如果Manager节点发生故障，可以平滑地移交给Manager2来接管。

对于应用程序来说，统一通过VIP访问。如果在此基础上考虑中间件方案，数据访问策略会更加复杂。

对于这样一个基本的解决方案，如果从多个维度去钻取，你会发现需要注意的地方很多，所以问题无处不在。幸运的是，在 MHA 几乎傍晚考虑的事情。简单来说，主要有以下几种场景需要考虑：

主库宕机

从库宕机

重启数据库主库

重启数据库从库

从库应用延迟

主从网络延迟

主库服务器宕机

从数据库服务器宕机

一主多从切换优先级

网络抖动导致切换

手动主从切换< /p>

主节点IP调整

从节点IP调整

添加从节点

删除从节点

防止网络抖动

半同步插件对MHA的影响

定制MHAScript

所以上面的方案需要一定程度的考虑。如果是下图表示的话，就会出现一些如下红色警告。因此，各个层面都可能出现问题和异常。如何尽量减少对b的影响业务并保持持续访问业务部门是重中之重。

举个比较纠结的问题，如果MHA Manager节点到主数据库数据库的网络出现抖动，导致短时间内无法访问，我们希望这个过程不会造成灾难。切换，但是如果时间太长，2、3分钟都无法访问，这个时候是切换还是不切换呢？目前信息还比较少。如果我们添加应用服务器的角色，如果应用服务器是可访问的，那么就不会被砍掉。如果应用程序访问受到影响，那么它将被切断。而且根据我们的测试，MHA0.56和0.57之间还是存在一些差异的。在测试了多种环境、测试了多种特性之后，只有将它们结合起来，我们才能发现MHA的考虑会更加全面。也就是说，只有了解整个故事的始末，我们才能更好地把握MHA 并看到更多问题。我们尝试对其进行定制，使其更适合当前的业务需求。

以上就是《如何使用MySQL高可用解决方案MHA》一文的全部内容。感谢您的阅读！相信大家都有一定的了解，希望分享的内容对大家有所帮助。如果您想了解更多知识，请关注行业资讯频道！