1. 简介

MHA（Master High Availability）是一个高效的开源MySQL高可用性解决方案。由日本开发者yoshinorim（前DeNA员工，现在Facebook）创建，MHA支持MySQL的主从复制架构，自动化主节点故障转移。当主节点发生故障，MHA能迅速将最新数据的从节点升级为新主节点。这个过程中，MHA从其他从节点获取额外信息，确保数据一致性。MHA还能在线切换主节点，按需调整主从节点关系。它已被证明是一个成熟的MySQL高可用方案，能在30秒内完成故障切换，并最大限度地保证数据一致性。值得一提的是，淘宝也在开发一个类似的产品TMHA，目前支持一主一从架构。

2. MHA服务

MHA服务包括两种角色：MHA Manager（管理节点）和MHA Node（数据节点）。

• MHA Manager：通常部署在一台独立的机器上，管理多个master/slave集群，每个集群称为一个application。它负责整个集群的管理和协调。
• MHA Node：安装在每台MySQL服务器（无论是master、slave还是manager）上。它负责监控、解析日志和加快故障恢复的过程。

工具与功能

MHA提供了一系列工具，分布在Manager节点和Node节点上：

• Manager节点工具：
  • masterha_check_ssh：检测SSH环境。
  • masterha_check_repl：检测MySQL复制环境。
  • masterha_manager：MHA的主服务程序。
  • masterha_check_status：探测MHA运行状态。
  • masterha_master_monitor：监测MySQL主节点可用性。
  • masterha_master_switch：切换主节点的工具。
  • masterha_conf_host：添加或删除配置节点。
  • masterha_stop：关闭MHA服务的工具。
• Node节点工具：（这些通常由Manager的脚本触发，无需手动操作）
  • save_binary_logs：保存并复制主节点的二进制日志。
  • apply_diff_relay_logs：识别并应用差异中继日志事件。
  • purge_relay_logs：清除中继日志。
• 自定义扩展：
  • secondary_check_script：通过多网络路由检测主节点可用性。
  • master_ip_failover_script：更新应用程序使用的master IP。
  • report_script：发送报告。
  • init_conf_load_script：加载初始配置参数。
  • master_ip_online_change_script：更新主节点IP地址。

工作原理

MHA的工作原理可以概括为以下几个步骤：

1. 从故障的master节点保存二进制日志事件（binlog events）。
2. 识别拥有最新更新的slave节点。
3. 将差异的中继日志（relay log）应用到其他slave节点。
4. 应用从master节点保存的二进制日志事件。
5. 提升一个slave节点为新master。
6. 使其他slave节点开始复制新master的数据。

3.MySQL Replication 环境的实验配置

3.1 准备实验 MySQL Replication 环境

3.1.1 相关配置

在本实验中，我们将设置一个包含四个节点的 MySQL Replication 环境，运行于 CentOS 7.3 系统。MHA (Master High Availability) 对 MySQL 复制环境有特定的配置需求，例如：

• 所有节点必须开启二进制日志（bin-log）和中继日志（relay-log）。
• 从节点（Slave）需设置为只读模式（read-only）。
• 关闭中继日志自动清理功能（relay_log_purge）。

节点配置如下：

• Manager (192.168.37.111): 作为控制器，负责监控和管理。
• Master (192.168.37.122): 数据库主服务器。配置了 bin-log 和 relay-log，关闭了 relay_log_purge。
• Slave1 和 Slave2 (192.168.37.133 和 192.168.37.144): 数据库从服务器。与 Master 相同的日志配置。

为方便操作，我们在所有节点的 /etc/hosts 文件中添加了对应的域名解析配置。

3.1.2 主节点（Master）的初始配置

对于主节点 Master 的数据库配置，我们进行以下设置：

• 设置 server-id 为 1，以保证集群中节点 ID 的唯一性。
• 开启二进制日志（log-bin）和中继日志（relay-log）。
• 关闭名称解析（skip_name_resolve，非必须）。

完成配置后，重启 MariaDB 服务以应用更改。

3.1.3 从节点（Slave）的配置

对于两个从节点 Slave，我们进行以下操作：

• 设置唯一的 server-id（2 和 3）。
• 开启中继日志（relay-log）和二进制日志（log-bin）。
• 启用只读模式（read_only）和日志更新（log_slave_updates）。
• 根据需要设置中继日志清理（relay_log_purge）。
• 可选关闭名称解析（skip_name_resolve）。

每次配置更改后，重启 MariaDB 服务以应用设置。

3.1.4 配置一主多从复制架构

在 Master 节点上，我们配置了权限以允许 Slave 连接和复制。具体命令包括授予复制权限和显示 Master 状态。

在每个 Slave 节点上，我们设置了连接到 Master 的参数，启动了复制服务，并检查了复制状态。

以上步骤完成了 MySQL Replication 环境的基本配置。

3.2 安装配置MHA

3.2.1 在Master节点进行授权

• 目标：在所有MySQL节点中授权一个具有管理权限的用户，以便在本地网络中远程访问其他节点。
• 操作：在Master节点运行SQL语句授权。
  • 示例命令：grant all on *.* to 'mhaadmin'@'192.168.%.%' identified by 'mhapass';

3.2.2 准备SSH互通环境

• 目的：在MHA集群中，各节点需要通过SSH互信通信来实现远程控制和数据管理。
• 步骤：
  1. 在Manager节点生成密钥对。
  2. 设置Manager节点可以远程连接本地主机。
  3. 将私钥文件和authorized_keys文件复制给所有其他节点。
  4. 在所有节点上进行上述操作。
  5. 验证所有节点的SSH无密码互通。

3.2.3 安装MHA包

• 操作：在Manager节点和其他节点上安装MHA包。
  • 包：
    • 所有节点：mha4mysql-node-0.56-0.el6.norch.rpm
    • Manager节点额外安装：mha4mysql-manager-0.56-0.el6.noarch.rpm
  • 安装方法：使用rz命令上传包，然后使用yum进行安装。

3.2.4 初始化MHA，进行配置

• 配置文件：Manager节点为每个监控的master/slave集群提供专用配置文件。
• 文件位置：全局配置文件位于/etc/masterha_default.cnf，或者通过application的配置提供。

3.2.5 定义MHA管理配置文件

• 步骤：在MySQL主节点上为MHA创建管理用户，以便于后续使用。
• 配置：创建/etc/mha_master目录并编写mha.cnf文件，配置包括管理用户、密码、工作目录等。

3.2.6 对四个节点进行检测

• SSH互信通信检测：在Manager机器上运行命令检测SSH连接。
• MySQL复制集群连接配置检测：
  • 使用masterha_check_repl命令检查。
  • 如有错误，可能需在master节点上创建从节点账号。
  • 再次运行检测命令以验证配置。

总结

此文档详细介绍了MHA的安装配置过程，包括授权、SSH互通设置、MHA包安装、配置文件定义和系统检测。这些步骤确保了MHA集群的正确安装和高效运行。

3.3 启动 MHA

在 manager 节点上执行以下命令来启动 MHA：

nohup masterha_manager -conf=/etc/mha_master/mha.cnf &> /etc/mha_master/manager.log &

启动成功后，检查 master 节点的状态：

masterha_check_status -conf=/etc/mha_master/mha.cnf

如果服务正常运行，将显示 mha (pid:7598) is running(0:PING_OK)。要停止 MHA，使用：

masterha_stop -conf=/etc/mha_master/mha.cnf

3.4 测试 MHA 故障转移

1. 模拟主节点崩溃：在 master 节点关闭 mariadb 服务。

   killall -9 mysqld mysqld_safe rm -rf /var/lib/mysql/*

2. 查看 manager 节点日志：

   tail -200 /etc/mha_master/manager.log

   日志显示 manager 检测到节点故障，并自动将 192.168.37.133 提升为主节点。

3.5 修复复制集群

1. 准备新的 MySQL 节点：基于 master 节点的备份恢复数据，配置为新的 master 的从节点。
2. 备份和数据恢复：在新的 master 节点进行备份，将数据恢复到新节点。
3. 配置主从关系：设置新的主节点和从节点，检查主从状态。

3.6 再次检查操作

1. 使用 masterha_check_repl 检查复制状态。
2. 如果无误，重新启动 manager 并查看状态：

   masterha_manager -conf=/etc/mha_master/mha.cnf > /etc/mha_master/manager.log 2>&1 & masterha_check_status -conf=/etc/mha_master/mha.cnf

3.7 故障转换恢复注意事项

1. 备份和手动提升：在从节点上做备份，并将主节点手动提升为从节点。
2. 配置文件修改：自动转换后，可能需要手动修复主节点并修改配置文件。
3. 重新运行检测命令：手动修复后，再次运行检测命令以确保恢复成功。

以上步骤详细介绍了如何启动和管理 MHA，以及在出现问题时的故障排查和修复流程。