MySQL 学习（12）—— MHA 高可用 | 8月更文挑战

开坦克的贝吉塔
649 阅读13分钟

“这是我参与8月更文挑战的第12天，活动详情查看：8月更文挑战”

1. 环境搭建

1.1 配置关键软连接

ln -s /data/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql          /usr/bin/mysql

1.2 配置各节点互信

db01：
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp  -r  /root/.ssh  10.0.0.52:/root
scp  -r  /root/.ssh  10.0.0.53:/root
各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

1.3 下载 MHA 软件

mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

1.4 所有节点安装 Node 软件依赖包

yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

1.5 在 db-master 主库中创建 MHA 需要的用户

grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';

1.6 Manager 软件安装（db-slave02）

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

1.7 配置文件准备(db-slave02)

创建配置文件目录
 mkdir -p /etc/mha
创建日志目录
 mkdir -p /var/log/mha/app1
编辑mha配置文件
vim /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306

1.8 状态检查

### 互信检查
masterha_check_ssh  --conf=/etc/mha/app1.cnf
Fri Apr 19 16:39:34 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:39:34 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Starting SSH connection tests..
Fri Apr 19 16:39:35 2019 - [debug]
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:34 2019 - [debug]   ok.
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:36 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:36 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [info] All SSH connection tests passed successfully.

1.9 主从状态检查

[root@db03 ~]# masterha_check_ssh  --conf=/etc/mha/app1.cnf
Fri Apr 19 16:39:34 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:39:34 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:39:34 2019 - [info] Starting SSH connection tests..
Fri Apr 19 16:39:35 2019 - [debug]
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:34 2019 - [debug]   ok.
Fri Apr 19 16:39:34 2019 - [debug]  Connecting via SSH from root@10.0.0.51(10.0.0.51:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:36 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.52(10.0.0.52:22) to root@10.0.0.53(10.0.0.53:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [debug]
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.51(10.0.0.51:22)..
Fri Apr 19 16:39:35 2019 - [debug]   ok.
Fri Apr 19 16:39:35 2019 - [debug]  Connecting via SSH from root@10.0.0.53(10.0.0.53:22) to root@10.0.0.52(10.0.0.52:22)..
Fri Apr 19 16:39:36 2019 - [debug]   ok.
Fri Apr 19 16:39:37 2019 - [info] All SSH connection tests passed successfully.
[root@db03 ~]# masterha_check_repl  --conf=/etc/mha/app1.cnf
Fri Apr 19 16:40:50 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Apr 19 16:40:50 2019 - [info] Reading application default configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] Reading server configuration from /etc/mha/app1.cnf..
Fri Apr 19 16:40:50 2019 - [info] MHA::MasterMonitor version 0.56.
Fri Apr 19 16:40:51 2019 - [info] GTID failover mode = 1
Fri Apr 19 16:40:51 2019 - [info] Dead Servers:
Fri Apr 19 16:40:51 2019 - [info] Alive Servers:
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.52(10.0.0.52:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.53(10.0.0.53:3306)
Fri Apr 19 16:40:51 2019 - [info] Alive Slaves:
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.52(10.0.0.52:3306)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info]     GTID ON
Fri Apr 19 16:40:51 2019 - [info]     Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info]   10.0.0.53(10.0.0.53:3306)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Fri Apr 19 16:40:51 2019 - [info]     GTID ON
Fri Apr 19 16:40:51 2019 - [info]     Replicating from 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Current Alive Master: 10.0.0.51(10.0.0.51:3306)
Fri Apr 19 16:40:51 2019 - [info] Checking slave configurations..
Fri Apr 19 16:40:51 2019 - [info]  read_only=1 is not set on slave 10.0.0.52(10.0.0.52:3306).
Fri Apr 19 16:40:51 2019 - [info]  read_only=1 is not set on slave 10.0.0.53(10.0.0.53:3306).
Fri Apr 19 16:40:51 2019 - [info] Checking replication filtering settings..
Fri Apr 19 16:40:51 2019 - [info]  binlog_do_db= , binlog_ignore_db=
Fri Apr 19 16:40:51 2019 - [info]  Replication filtering check ok.
Fri Apr 19 16:40:51 2019 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Fri Apr 19 16:40:51 2019 - [info] Checking SSH publickey authentication settings on the current master..
Fri Apr 19 16:40:51 2019 - [info] HealthCheck: SSH to 10.0.0.51 is reachable.
Fri Apr 19 16:40:51 2019 - [info]
10.0.0.51(10.0.0.51:3306) (current master)
 +--10.0.0.52(10.0.0.52:3306)
 +--10.0.0.53(10.0.0.53:3306)

Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.52..
Fri Apr 19 16:40:51 2019 - [info]  ok.
Fri Apr 19 16:40:51 2019 - [info] Checking replication health on 10.0.0.53..
Fri Apr 19 16:40:51 2019 - [info]  ok.
Fri Apr 19 16:40:51 2019 - [warning] master_ip_failover_script is not defined.
Fri Apr 19 16:40:51 2019 - [warning] shutdown_script is not defined.
Fri Apr 19 16:40:51 2019 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

1.10 开启MHA(db-slave02)：

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

1.11 查看 MHA 状态

[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.51 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 51    |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.52 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 52    |
+---------------+-------+
[root@db03 ~]# mysql -umha -pmha -h 10.0.0.53 -e "show variables like 'server_id'"
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 53    |
+---------------+-------+

2. MHA 架构软件结构说明

2.1 节点规划

数据库节点，必须至少是 1 主 2 从独立实例。（不支持一台机器多实例）

MHA 管理节点，最好是独立一台机器。MHA 架构如下：

MHA 架构

  • 节点规划
    • manager 端：db03
    • node 端：db01、db02、db03
      • 一主：db01
      • 两从：db02、db03

2.2 MHA 软件的构成

  • Manager 工具包主要包括以下几个工具：

    • masterha_manager：启动 MHA
    • masterha_check_ssh：检查 MHA 的 SSH 配置状况
    • masterha_cheak_repl：检查 MySQL 复制状况
    • masterha_master_monitor：检测 master 是否宕机
    • masterha_check_status：检测当前 MHA 运行状态
    • masterha_master_switch：控制故障转移（自动或者手动）
    • masterha_conf_host：添加或删除配置的 server 信息

  • Node 工具包主要包括以下几个工具（这些工具通常由 MHA Manager 的脚本触发，无需人为操作）：

    • save_binary_logs：保存和复制 master 的二进制信息
    • apply_diff_relay_log：识别差异的中继日志事件并将其差异的时间应用于其他的
    • purge_relay_logs：清除中继日志（不会阻塞 SQL 线程）

3. MHA 配置过程细节说明

3.1 软连接

ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql

原因：MHA 调用的时候，只能调用 /usr/bin/mysqlbinlog 和 /usr/bin/mysql 下的命令，不能找到你自己配置的环境路径。

3.2 配置互信

3.3 安装软件包

3.4 在 db01 主库上创建 MHA 需要的用户

3.5 Manager 软件安装（db03）

最好安装在一台新的机器上，如果不可以的话，就安装在从库上。

不能安装在主库上，因为 Manager 的作用就是用来监控主库，假如主库断电了。那么就没法监控了。

3.6 配置文件准备

除了 server_id 不一样，其他最好都一样。

3.7 状态检查

3.8 开启 MHA（db03）

4. MHA Failover 过程详解

4.1 什么是 Failover？

  • 故障转移
  • 主库宕机，一直到业务恢复正常的处理过程（自动）

4.2 Failover 让你实现怎么做？

  1. 快速监控到主库宕机：mysqladmin ping

  2. 选择新主

    1. show slave status\G
      1. Retrieved_Gtid_Set
      2. Executed_Gtid_Set

  3. 数据补偿（前提：SSH 能连接上）

  4. 解除从库身份

  5. 剩余从库和新主库构建主从关系

  6. 应用透明

  7. 故障节点自愈（待开发...）

  8. 故障提醒

4.3 MHA 的 Failover 如何实现？

从启动 -> 故障 -> 转移 -> 业务恢复

  1. MHA 通过 masterha_manager 脚本来启动 MHA 的功能

  2. 在 manager 启动之前，会自动检查 ssh 互信（masterha_check_ssh）和主从状态（masterha_check_repl）

  3. MHA-manager 通过 masterha_master_monitor 脚本（每隔 ping_interval 秒）

  4. masterha_master_monitor 探测主库 3 次无心跳后，就认为主库宕机了。

  5. 进行选主过程

    1. 算法一：

      1. 读取配置文件中是否有强制选主参数

      2. candidate_master=1

      3. 想预选那个当主库就设置在哪个配置下

      4. check_repl_delay=0

        1. check_repl_delay 用来检查主库和从库之间的差异，如果差异太大，就不选这个库当做主库
        2. 如果不想检查主从延时的差异性，就设置 check_repl_delay=0

      5. 没有设置强制选主参数，就进入算法二

    2. 算法二：
      1. 自动判断所有从库的日志量，将最接近主库日志数据的从库作为新主库
    3. 算法三：
      1. 按照配置文件先后顺序的进行选新主

  6. 数据补偿

    1. 判断主库 SSH 的连通性

      1. 情况一：能连

        1. 调用 save_binary_logs 脚本，立即保存缺失部分的binlog 到各个从节点，恢复

      2. 情况二：无法连

        1. 调用 apply_diff_relay_logs 脚本，计算从库的 relaylog 的差异，恢复到 2 号从库

  7. 解除从库身份

  8. 剩余从库和新主库构建主从关系

  9. 应用透明

  10. 故障节点自愈（待开发）

  11. 故障提醒

扩展：candidate_master=1 的应用场景？

  1. MHA + KeepAlive VIP（早期 MHA 架构）
  2. 多地多中心

5. MHA 应用透明（VIP）

  • 将文件复制到 /usr/local/bin 目录下
cp /root/master_ip_failover.txt /usr/local/bin/master_ip_failover
  • 修改配置文件
vim /usr/local/bin/master_ip_failover

my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin.ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
  • 将中文字符改为英文：
dos2unix master_ip_failvoer
  • 将文件增加执行权限
chmod +x master_ip_failvoer
  • 将脚本加入到配置文件中
vim /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover
  • db01：手工添加 VIP
ifconfig eth0:1 10.0.0.55/24
  • db03：重启 MHA
masterha_stop --conf=/etc/mha/app1.cnf

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

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

6. MHA 故障提醒

MHA 是一次性功能，一旦发生故障，就不能够再次提供 MHA 功能，所以需要出现问题的时候，立即恢复架构。

cp -r email /usr/local/bin/
cd /usr/local/bin/email/
chmod -x *

vim /etc/mha/app1.cnf
report_script+/usr/local/bin/email/send

重启 MHA

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

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

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

7. 额外的数据补偿（binlog_server）

  1. 找一台额外的机器，必须要有 5.6 以上的版本，支持 GTID 并开启，我们直接使用第二个 slave（db03）
vim /etc/mha.app1.cnf

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
  1. 创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
  1. 拉取主库 binlog 日志
cd /data/mysql/binlog -> 必须进入到自己创建好的目录
mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &

注意：拉取日志的起点，需要按照目前主库正在使用的 binlog 为起点。

  1. 重启 MHA-manager
masterha_stop --conf=/etc/mha/app1.cnf

nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

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

7.1 为什么 binlog 数据一定会保存成功

单节点的话，当我们输入 commit，数据会保存 redo log，binlog，然后状态置为 commit 数据就保存成功了。

有个 binlog server 呢，binlog 只有同步到远程服务器成功了，执行才会成功。多了一步（有点疑问）

8. 故障模拟及故障处理

8.1 宕机 db01 数据库

/etc/init.d/mysqld stop

观察manager  日志 tail -f /var/log/mha/app1/manager
末尾必须显示successfully，才算正常切换成功。

8.2 故障恢复

  1. 启动故障节点
[root@db01 ~]# /etc/init.d/mysqld start
  1. 恢复 1 主 2 从（现在是 1 主 1 从）

在 10.0.0.51 上执行一下：

CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1,
MASTER_USER='repl',
MASTER_PASSWORD='123';
start slave ;
  1. 恢复配置文件（db03）

server1 会丢失，因为宕机就会清除故障节点配置信息，所以需要增加上

[server1]
hostname=10.0.0.51
port=3306
  1. 启动 MHA
nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
  1. 恢复 binlog server
cd /data/mysql/binlog
rm -rf /data/mysql/binlog/*
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &

9. MHA 的故障排查

9.1 搭建过程中排查

  1. 检查脚本
masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf

1 主 2 从复制环境

  1. 配置文件

    1. 节点地址
    2. 端口
    3. vip 和 send 邮件，脚本指定位置和权限

  2. 软连接

9.2 切换过程中的问题

查看 /var/log/mha/app1/manager

脚本问题比较多一些

  • vip
  • send
  • binlog

9.3 故障环境恢复

  1. 检查各个节点是否启动

  2. 找到主库是谁？

    1. show slave status\G

  3. 恢复 1 主 2 从

    1. change master to;
    2. start slave;

  4. 检查配置文件，恢复节点信息

  5. 检查 vip 和 binlog server

    1. 检查 vip 是否在主库，如果不在，手工调整到主库

      1. ifconfig

    2. 重新启动 binlog server 拉取

  6. 启动 Manager

10. Manager 额外参数介绍

主库宕机谁来接管？

  1. 所有从节点日志都是一致的，默认会以配置文件的顺序去选择一个新主。

  2. 从节点日志不一致，自动选择最接近于主库的从库

  3. 如果对于某节点设定了权重（candidate_master=1），权重节点会优先选择。但是此节点日志量落后主库 100M 日志的话，也不会被选择。可以配合 check_repl_delay=0，关闭日志量的检查，强制选择候选节点。

  4. ping_interval=1：

    1. 设置监控主库，发送 ping 包的时间间隔，尝试三次没有回应的时候自动进行 failover

  5. candidate_master=1：

    1. 设置为候选 master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的 slave

  6. check_repl_delay=0：

    1. 默认情况下如果一个 slave 落后 master 100M 的 relay logs 的话，MHA 将不会选择该 slave 作为一个新的 master，因为对于这个 slave 的恢复需要花费很长时间，通过设置 check_repl_delay=0，MHA 触发切换在选择一个新的 master 的时候将会忽略复制延时，这个参数对于设置了 candidate_master=1 的主机非常有用，因为这个候选主在切换的过程中一定是新的 master

11. MHA 的 VIP 功能

  1. 准备脚本
  2. 修改脚本配置
  3. 修改 Manager 配置文件
  4. 主库上生成第一个 VIP 地址
  5. 重启 MHA
avatar
文章
阅读
粉丝