MaxScale：实现MySQL读写分离与负载均衡的中间件利器(3)

通过实验可以看到,在部分 slave 发生故障时,MaxScale 可以自动识别出来,并移除路由列表,当故障恢复重新上线后,MaxScale 也能自动将其加入路由,过程透明.

分别登陆 slave1 和 slave2 的MySQL,执行停止复制的命令

查看 MaxScale 服务器状态

发现各个服务器的角色都识别不出来了.

查看日志：

从日志中看到,MaxScale 发现2个slave 和 master 都丢了,然后报错：没有 master 了.

客户端连接 MaxScale 时也失败了.

说明从服务器全部失效后,会导致 master 也无法识别,使整个数据库服务都失效了.

对于 slave 全部失效的情况,能否让 master 还可用?这样至少可以正常提供数据库服务.

这需要修改 MaxScale 的配置,告诉 MaxScale 我们需要一个稳定的 master.

处理过程

先恢复两个 slave,让集群回到正常状态,登陆两个 slave 的MySQL.

修改 MaxScale 配置文件,添加新的配置.

找到 [MySQL Monitor] 部分,添加：

保存退出,然后重启 MaxScale.

验证

停掉两台 slave,查看 MaxScale 服务器状态.

可以看到,虽然 slave 都无法识别了,但 master 还在,并提示处于稳定状态

客户端执行请求：

客户端可以连接 MaxScale,而且请求都转到了 master 上,说明 slave 全部失效时,由 master 支撑了全部请求.

当恢复两个 slave 后,整体状态自动恢复正常,从客户端执行请求时,又可以转到 slave 上.

通过测试发现,在部分 slave 故障情况下,对于客户端是完全透明的,当全部 slave 故障时,经过简单的配置,MaxScale 也可以很好地处理.

（编辑：ASP站长网）