MySQL高可用MHA集群
一、MHA概述
1.1 什么是 MHA
MHA(MasterHigh Availability)是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。
MHA 的出现就是解决MySQL 单点故障的问题。
MySQL故障切换过程中,MHA能做到0-30秒内自动完成故障切换操作。
MHA能在故障切换的过程中最大程度上保证数据的一致性,以达到真正意义上的高可用。
1.2 MHA 的组成
1)MHA Node(数据节点)
- MHA Node 运行在每台 MySQL 服务器上。
2)MHA Manager(管理节点)
- MHA Manager 可以单独部署在一台独立的机器上,管理多个 master-slave 集群;也可以部署在一台 slave 节点上。
- MHA Manager 会定时探测集群中的 master 节点。当 master 出现故障时,它可以自动将最新数据的 slave 提升为新的 master, 然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。
1.3 MHA 的特点
- 自动故障切换过程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的保证数据不丢失。
- 使用半同步复制,可以大大降低数据丢失的风险,如果只有一个slave已经收到了最新的二进制日志,MHA可以将最新的二进制日志应用于其他所有的slave服务器上,因此可以保证所有节点的数据一致性。
- 目前MHA支持一主多从架构,最少三台服务器,即一主两从。

二、MySQL MHA搭建准备
2.1 实验思路
1)MHA架构:①数据库安装 ②一主两从 ③MHA搭建
2)故障模拟:①主库失效 ②备选主库成为主库 ③原故障主库恢复重新加入到MHA成为从库
2.2 实验准备
MHA一主两从高可用集群示意图:
三、搭建 MySQL MHA
3.1 配置主从复制
1、四台服务器都关闭防火墙
2、修改 Master、Slave1、Slave2 节点的主机名


3、 在Master、Slave1、Slave2添加主机映射关系

4、修改 Master、Slave1、Slave2 节点的 Mysql主配置文件/etc/my.cnf
Master节点,开启二进制日志。
Slave1、Slave2 节点,开启二进制日志和中继日志。



5、在 Master、Slave1、Slave2 节点上都创建两个软链接
6、登录数据库进行授权
对slave和manager进行授权。
所有数据库节点,授权给manager服务器:
7、配置主从同步
在 Master 节点查看二进制文件和同步点(即偏移量),在 Slave1、Slave2 节点执行同步操作。
1)在 Master 节点查看二进制文件和同步点:
2)在 Slave1、Slave2 节点执行同步操作:

3)两个从库必须设置为只读模式:
4)在Master主库插入数据,slave中验证数据同步:


3.2 配置MHA
1、所有服务器安装MHA软件
- 对于每个操作系统版本不一样,这里 CentOS7.4 必须选择 0.57 版本。
- 在所有服务器上必须先安装 node 组件,最后在 MHA-manager 节点上安装 manager 组件,因为 manager组件 依赖 node 组件。

(2)先在所有服务器上安装 node 组件:

(3)最后在 MHA manager 节点上安装 manager 组件:

小贴士:
#manager 组件安装后在/usr/local/bin/ 下面会生成几个工具,主要包括以下几个:
| 工具 | 说明 |
|---|---|
| masterha_check_ssh | 检查 MHA 的 SSH 配置状况 |
| masterha_check_repl | 检查 MySQL 复制状况 |
| masterha_manger | 启动 manager的脚本 |
| masterha_check_status | 检测当前 MHA 运行状态 |
| masterha_master_monitor | 检测 master 是否宕机 |
| masterha_master_switch | 控制故障转移(自动或者手动) |
| masterha_conf_host | 添加或删除配置的 server 信息 |
| masterha_stop | 关闭manager |
#node 组件安装后也会在/usr/local/bin/ 下面会生成几个脚本(这些工具通常由 MHAManager 的脚本触发,无需人为操作)主要如下:
| 工具 | 说明 |
|---|---|
| save_binary_logs | 保存和复制 master 的二进制日志 |
| apply_diff_relay_logs | 识别差异的中继日志事件并将其差异的事件应用于其他的 slave |
| filter_mysqlbinlog | 去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具) |
| purge_relay_logs | 清除中继日志(不会阻塞 SQL 线程) |


(2)在 mysql1 上配置到数据库节点 mysql2 和 mysql3 的无密码认证

(3)在 mysql2 上配置到数据库节点 mysql1 和 mysql3 的无密码认证

(4)在 mysql3 上配置到数据库节点 mysql1 和 mysql2 的无密码认证

3、在 manager 节点上配置 MHA
(1)在 manager 节点上复制相关脚本到/usr/local/bin/ 目录。
(2)将master_ip_failover(自动切换时 VIP 的管理脚本)复制到/usr/local/bin 目录,这里使用master_ip_failover脚本来管理 VIP 和故障切换。
(3)修改/usr/local/bin/master_ip_failover 脚本,删除原有内容,所有内容全都重新添加。
4、 manager节点编辑配置文件,管理 mysql 节点服务器
创建 MHA 软件目录并拷贝配置文件,这里使用app1.cnf配置文件来管理 mysql 节点服务器。
编辑配置文件 /etc/masterha/app1.cnf
5、第一次配置需要在 Master 节点上手动开启虚拟IP
/sbin/ifconfig ens33:1 192.168.72.100/24
6、在 manager 节点上测试 ssh 无密码认证
在 manager 节点上测试 ssh 无密码认证,如果正常最后会输出 successfully,如下所示。

7、在 manager 节点上测试 mysql 主从连接情况
在 manager 节点上测试 mysql 主从连接情况,最后出现MySQL Replication Health is OK 字样说明正常。如下所示。


8、在 manager 节点上启动 MHA
9、在 manager 节点上查看 MHA 状态 和 MHA 日志,可以看到 master的地址
10、在Mysql1上查看 VIP 地址 192.168.72.100 是否存在
查看 Mysql1 的 VIP 地址 192.168.72.100 是否存在,这个 VIP 地址不会因为 manager 节点停止 MHA 服务而消失。
3.3 故障模拟
在Mysql1上停止mysql服务,MHA 会自动修改 app1.cnf 文件内容,将宕机的 mysql1 节点删除。 mysql2 会自动接管 VIP,成为新的master。
(1)在 Master 节点 Mysql1 上停止mysql服务:
(2)在 manager 节点上监控观察日志记录,manager选举了mysql2作为新的主服务器


(3)查看manager节点的配置文件。MHA 会自动修改 app1.cnf 文件内容,将宕机的 mysql1 节点删除

(4) mysql2 已接管 VIP

3.4 故障修复
1)修复mysql1(即修复原来的主节点)

2)修复主从数据
在新的主库服务器 Mysql2 查看二进制日志文件和同步点:
在原主库服务器 mysql1 执行同步操作,同步现在主库中的数据:

3)在 manager 节点上修改配置文件app1.cnf
重新把三台mysql节点服务器这个记录添加进去,因为它检测到主节点失效时候会自动删除主节点。
将mysql1添加为新的候选master。
4)在 manager 节点上启动 MHA
小贴士
解决中英字符不兼容报错的问题,可执行如下语句:
dos2unix /usr/local/bin/master_ip_failover


浙公网安备 33010602011771号