什么是 MHA
MHA(Master High Availability) 是自动的 master 故障转移和 slave 提升的软件包。它是基于标准的 MySQL 复制(异步/半同步).
MHA 有两部分组成:MHA Manager(管理节点)和 MHA Node(数据节点)。
MHA Manager 可以单独部署在一台独立机器上管理多个 master-slave 集群,也可以部署在一台 slave 上。MHA Manager 探测集群的 node 节点,当发现 master 出现故障的时候,它可以自动将具有最新数据的 slave 提升为新的 master,然后将所有其它的 slave 指向新的 master。整个故障转移过程对应用程序是透明的。
MHA node 运行在每台 MySQL 服务器上(master/slave/manager),它通过监控具备解析和清理 logs 功能的脚本来加快故障转移的过程。
作为前提条件,应先配置 MySQL 复制,并设置 SSH 公钥免密码登录。下面以 CentOS 为例来说明,最好先安装 EPEL(http://fedoraproject.org/wiki/EPEL),不然 YUM 可能找不到某些软件包。MHA 由 Node 和 Manager 组成,Node 运行在每一台 MySQL 服务器上, 也就是说,不管是 MySQL 主服务器,还是 MySQL 从服务器,都要安装 Node,而 Manager 通常运行在独立的服务器上,但如果硬件资源吃紧,也可以用一台 MySQL 从服务器来 兼职 Manager 的角色。
MHA 工作原理和工具包
工作原理
- 从宕机崩溃的 master 保存二进制日志事件(binlog events) -识别含有最新更新的 slave
- 应用差异的中继日志(relay log)到其它 slave
- 应用从 master 保存的二进制日志事件(binlog events) -提升一个 slave 为新 master
- 使其它的 slave 连接新的 master 进行复制
Manager 工具
- masterha_check_ssh : 检查 MHA 的 SSH 配置
- masterha_check_repl : 检查 MySQL 复制
- masterha_manager : 启动 MHA
- masterha_check_status : 检测当前 MHA 运行状态
- masterha_master_monitor : 监测 master 是否宕机
- masterha_master_switch : 控制故障转移(自动或手动)
- masterha_conf_host : 添加或删除配置的 server 信息
Node 工具(这些工具通常由 MHA Manager 的脚本触发,无需人手操作)
- save_binary_logs : 保存和复制 master 的二进制日志
- apply_diff_relay_logs : 识别差异的中继日志事件并应用于其它 slave
- filter_mysqlbinlog : 去除不必要的 ROLLBACK 事件(MHA 已不再使用这个工具)
- purge_relay_logs : 清除中继日志(不会阻塞 SQL 线程)
安装
略 。。。
通过集成的 perl 脚本实现 VIP 漂移
- master_ip_failover_script
- master_ip_online_change_script
两个文件的配置保持相同,具体如下(默认下载到的是没有如下的,需要手工修改): my $vip = ' 192.168.3.240 '; # Virtual IP
my $net_mask = "24"; #子网野码
my $key = "9999"; #为了标识的唯一性
my $nic = "em1"; #网卡名
my $ssh_start_vip = "sudo /sbin/ifconfig $nic:$key $vip/$net_mask;/sbin/arping -b -c 2 -w 30 -I $nic $vip"; #启动并朝交换机发送广播
my $ssh_stop_vip = "sudo /sbin/ifconfig $nic:$key down"; #关闭命令
保留中继日志和定期清理
- 默认情况下,从服务器上的中继日志在 SQL 线程执行完后会被自动删除的。但是这些 中继日志在恢复其他从服务器时候可能会被用到,因此需要禁用中继日志的自动清除和定期 清除旧的中继日志。定期清除中继日志需要考虑到复制延时的问题。删除大的文件需要一定 的时间,会导致严重的复制延时。为了避免复制延时,暂时为中继日志创建硬链接。
- MHA 节点包含 pure_relay_logs 命令工具,它可以为中继日志创建硬链接,执行 SET GLOBAL relay_log_purge=1,等待几秒中以便 SQL 线程切换到新的中继日志,再执行 SET GLOBAL relay_log_purge=0。
注意点
- mha manager 并会初始化虚拟 ip,只会切换 IP,所以请在开启 mha manager 前,在 master 增加 VIP
- 如果 master 以前是 slave,并且 slave 线程停止掉了,请 reset 掉,不然启动 manager 时会报错
- 防止脑裂发生,当网络抖动或者交换机异常的时候(默认check 3s 共三次),需要添加定期 check 网络问题,如果脑裂,需要有能力依靠 binlog 补齐,并快速关闭脑子机器所在 vip(经验是如果是 1主 2从 的架构,选择已经完成主从 Or 选择活跃连接数较高的一组为最新)
- mha manager 至少需要两台机器来进行 double check,三台就更好了
- 切换脚本可以做一些二次开发,比如添加重新修改监控、中继日志清理程序调整 & 各种各家不通的操作
- 非 root 打通的 SSH,需要注意用户权限添加到 MySQL 用户组,注意 ifconfig 权限需要给到,建议使用非 root 打通
- 具体切换过程,推荐大家先从看日志开始,日志还是很全面的
- MySQL高可用架构之MHA 原理与实践
- 如果是云上可以基于各种LB 来实现 VIP 的功能,需要修改切换脚本 (借用某 DBA 大佬的话,都云了,还用 MHA 个毛,直接买啊!)