完美替代MHA，Maxscale的高可用故障转移功能你大概还不知道

作者介绍

MHA（Master High Availability）是目前中小公司使用的常见MySQL高可用架构，但有些云厂商不支持虚拟VIP，或者VIP不是同网段的，固无法实现基于MHA或Keepalived漂移VIP形式的高可用使用场景。

于是针对这种情况，衍生出Cousul服务发现+MHA这种架构，架构如下图所示：

客户端PHP/JAVA应用程序访问Consul服务集群DNS域名，从Consul获取到后端MySQL的master地址，然后将写请求发送到master。MHA负责主从Failover故障转移和Switchover切换，当主从角色变化后，Consul服务能智能识别新的master，在这里Consul相当于一个Proxy代理中间件。另外，你需要额外自定义脚本来结合Consul，判断当前MySQL是主节点还是从节点。

细心的读者应该会发现一个问题，这个方案的成本是不是有些高了？我既得部署MHA，又得部署Consul，且自定义脚本可能缺乏测试和灵活性，显然恢复应该是自动的、经过全面测试的，并且最好包含在现有数据库可伸缩性环境中。

生产环境架构通常是越简单，排查定位问题越容易，能否再简单一些？我改几个配置文件，启动服务就可以完成上述功能呢？

答案是：Of course。

本文笔者讲述的MariaDB官方出品的Maxscale，集成了Consul+MHA的所有功能，不再依赖第三方工具，可以让你快速在Cloud云端上部署一套高可用架构，即使你的公司没有聘请专业MySQL DBA也完全ok。

为了满足此需求，MariaDB MaxScale 2.2版本里，在支持原有读写分离的基础上，又添加了主从复制集群管理功能，在最新版MaxScale 2.5版本里，实现了GUI图形化、可视化监控管理web页面。

（请注意！Failover以及Switchover和Rejoin仅支持基于GTID的复制一起使用，并且仅适用于简单的一主多从拓扑架构：即1个master后面跟着多个slave。）

Mariadbmon守护进程，会实时探测主从复制状态，可以通过执行故障转移，在线切换和重新加入来修改复制群集。

1）Failover：用最新的slave替换发生故障的master，故障转移分为Manual Failover和Automatic Failover。在当前已存在的主从复制环境中，MaxScale可以监控master主机故障，并且故障自动转移。

需要把loss-less无损半同步复制(semi replication)开启，参数rpl_semi_sync_master_wait_point=AFTER_SYNC，确保slave已经接收到了master的binlog，因为master宕机，MaxScale无法远程拷贝scp那一缺失的binlog，那么数据就出现不一致了。

2）Switchover：在线主从切换，类似MHA的masterha_master_switch  --master_state=alive。

如果机器需要维护，将master角色在线切换到其他主机上（例如更换原master坏掉的硬盘），这并不是master进程崩溃引起的故障转移。在线切换通常在0.5-2秒左右，并且会阻塞写（在原master上执行SET GLOBAL read_only=1命令设置全局只读，且执行FLUSH TABLES把所有的表强制关闭），建议在凌晨业务低峰期执行在线切换。

3）Rejoin：重新加入到新集群作为slave，即死掉的原master如何与提升为新的master建立同步复制关系？由于Maxscale是基于GTID模式的主从复制，全局事务号是唯一的，会自动执行CHANGE MASTER TO NEW_MASTER, MASTER_USE_GTID = current_pos命令，无需人工参与。

（请确保所有MySQL主从节点参数log_slave_updates=ON开启。）

Maxsclae：127.0.0.1，端口：4006

Master：127.0.0.1，端口：3312

Slave1：127.0.0.1，端口：3314

Slave2：127.0.0.1，端口：3316

1）安装MaxScale

2）创建密钥文件

密钥文件.secrets存放在/usr/local/maxscale/var/lib/maxscale/目录下。

3）创建加密密码

这里是对密码123456做加密，会生成如下加密字符串：

5CD3AF1688D20ECED2BECEF15C075BC6B02375FE27FFCAC3A12A5FFCBE4FB16C

这些加密后的字符串请保存好，之后要粘贴在maxscale.cnf配置文件里。

4）修改文件描述符65535

* soft nofile 65535

* hard nofile 65535

fs.file-max=65535

net.ipv4.ip_local_port_range = 1025 65000

net.ipv4.tcp_tw_reuse = 1

# 修改完毕后，reboot重启服务器生效

5）创建Maxscale监控账号

① SHOW MASTER STATUS语句更名为SHOW BINLOG STATUS

② REPLICATION CLIENT权限更名为BINLOG MONITOR

③ SHOW BINLOG EVENTS语句需要BINLOG MONITOR权限

④ SHOW SLAVE HOSTS语句需要REPLICATION MASTER ADMIN权限

⑤ SHOW SLAVE STATUS语句需要REPLICATION SLAVE ADMIN和SUPER权限

⑥ SHOW RELAYLOG EVENTS语句需要REPLICATION SLAVE ADMIN权限

MariaDB 10.5版本里，改为：

6）配置MaxScale服务

# cat usr/local/maxscale/etc/maxscale.cnf

maxscale.cnf配置文件分为全局模板、主机模板、故障转移监控模板、服务模板和服务监听模板，五大部分。

重要参数详解：

① 故障转移监控模板

#打开自动故障转移，false为关闭，需要人工执行命令去做故障转移，通常为true。

#打开自动重新加入，false为关闭，需要人工执行CHANGE MASTER TO NEW_MASTER, MASTER_USE_GTID = current_pos命令，通常为true。

# 3次连接失败，认定主库down掉，开始启动故障转移，默认是5次尝试。

# 假定slave库有延迟，在默认90秒时间内，没有同步完，自动关闭故障转移。通常默认值即可。

# 假定slave库有延迟，在默认90秒时间内，没有同步完，自动关闭在线切换。通常默认值即可。

# 当Maxscale连接不上master时，开启其他slave再次验证master是否故障。这样的好处是：防止网络抖动误切换（脑裂），造成数据不一致，其实现原理为：投票机制，当Maxscale无法连接MySQL主库，会试图从其他slave机器上去连接MySQL主库，只有双方都连接失败，才认定MySQL主库宕机。假如有一方可以连接MySQL主库，都不会切。

类似MHA的masterha_secondary_check命令二次检查，默认开启，无需关闭。

# 这个参数依赖于verify_master_failure，当开启后，从库在默认10秒内无法连接master，认定主库down掉。通常默认值即可。

② 服务模板

这里我们要定义一个服务，路由选择读写分离模块。你可以分离一部分select读取操作到slave从库上。它是基于statement的，解析SQL语句。在这里前端程序不需要修改代码，通过MaxScale对SQL语句解析，把读写请求自动路由到后端数据库节点上，从而实现读写分离。开源Percona ProxySQL中间件也是基于statement方式实现读写分离。

# 如果你担心数据有延迟，担心数据准确性问题，可以设置在主库上查询。默认读是不被路由到master，设置为true允许master用于读取。

# 允许两个slave进行读取

# 定义超过延迟1秒，把请求转发给master

# 由于Maxscale通过参数monitor_interval=2000，每隔2秒探测一次，可能存在主从延迟检测不到的情况。

例如主库上写入了一条数据，从库还没来得写入该记录。那么可以通过设置causal_reads=local，此时客户端在从库上查询会hang住，直至等待causal_reads_timeout=10，默认10秒，超时后请求会强制转发给master。

③ 服务监听模板

我们在上面已经完成了服务定义，那么为了让客户端可以请求访问，我们需再定义一个tcp协议端口。

service=RW_Split_Router

# 这里的RW_Split_Router模块名，要对应服务模块的名字

port=4006

# 读写分离端口，应用连接这个端口，可以自定义端口。 

7）启动服务

日志信息会记到到/usr/local/maxscale/var/log/maxscale/maxscale.log

此时所有的slave机器都自动设置为只读模式，可通过select @@read_only查看。

8）查看Maxscale后台管理信息

我们可以通过maxctrl后台管理命令查看主从复制集群状态信息，命令如下：

# maxctrl list servers

查看我们刚才注册的服务，命令如下：

# maxctrl list services

也可以通过GUI WEB图形页面查看，访问http://yourip:8989端口，登录名admin，密码mariadb，如下图所示：

通过mysqladmin shutdown命令关闭主库的mysqld进程。

Failover细节：

1）选择最新的slave作为master，依照以下顺序标准排列：

2）如果最新的slave具有未处理的中继日志，会根据参数failover_timeout=90等待90秒，超过90秒数据未同步完，则关闭故障转移。通过判断gtid_binlog_pos和gtid_current_pos值是否相等。

3）准备新的master

① 在最新的slave上，关闭复制进程执行命令：

并清空同步复制信息执行命令。

② 在最新的slave上，关闭只读read_only 执行命令。

③ 在最新的slave上，启用EVENT事件（MySQL定时任务）。

④ 接收客户端读写请求。

4）重定向所有slave指向新的master进行同步复制

① 停止同步复制，执行命令

② 指向新的master进行复制，执行命令

③ 开启同步复制，执行命令

5）检查所有slave复制是否正常，执行命令SHOW ALL SLAVES STATUS判断Slave_IO_Running和Slave_SQL_Running值是否都为双Yes。

通过以下命令可以实现手工故障切换：

这里的切换细节跟自动故障转移是一样的，为了节省篇幅，这里不再介绍。

目前的主是server1，从是server2。

通过以下命令可以实现在线切换：

Switchover细节

准备降级的旧master：

1）在旧的master上，开启只读read_only 执行命令。

SET STATEMENT max_statement_time=1 FOR SET GLOBAL 

read_only=1禁止数据写入。

2）终止SUPER权限超级用户的连接，通过以下命令找到超级用户连接Id：

然后执行KILL命令，因为read_only只读不影响SUPER权限超级用户更改数据。

3）执行FLUSH TABLES把所有表强制关闭。

4）执行FLUSH LOGS刷新二进制日志，以便所有binlog都刷到磁盘上。

5）在旧master上执行：SELECT @@gtid_current_pos, ，@@gtid_binlog_pos记录gtid事务号。

在新master上执行：SELECT MASTER_GTID_WAIT('GTID');如果执行结果都为0，表示已经完成数据同步，可以进行下一步切换，否则需要一直等待完成。

6）后面的步骤跟故障转移一样。

生产环境中，至少部署两个Maxscale服务，可以和后端MariaDB部署在一起，这样节省了网络IO请求转发带来的额外损耗，另外将Maxscale挂在云服务SLB后面做负载均衡。

注：由于GTID实现方式不同，Maxscale最新版暂不支持MySQL和Percona的故障转移切换，仅支持读写分离功能，这里特别要注意下。