共计 6899 个字符，预计需要花费 18 分钟才能阅读完成。
最近一直在瞎搬砖，最大的感触是运维工作难做。不过废话不多说，最近被分配了一项比较有意思的 task，尝试着非 root 用户搭建 MHA 并测试下能否成功漂移，以下是两天测试和文档编写的成果，分享给各位看客，欢迎交流学习。
测试的目的：
现行的主流搭建 MHA 使用的用户是 root 来传递公钥以及进行一些切换、摘除、添加 VIP 的工作，但 root 用户的权限过大，在生产上存在安全漏洞的风险，可以尝试使用一个普通的用户以较小的权限角色实现 MHA 的各项功能。
测试的环境：
1、两台 CentOS 服务器，iptables 关闭，配置为 8 核 8G 内存，系统 CentOS release 6.8 (Final)。服务器 IP 三个分别是 172.16.3.190/22、172.16.3.189/22 以及 VIP：172.16.3.123/22
2、数据库实例两台，版本保持一致为 5.7.18-log MySQL Community Server (GPL)。
测试的步骤：
1、配置 MHA 复制集（master-slave-manager），GTID+Semi-Sync+ 并行复制
2、安装 MHA 及基本环境配置
3、MHA 健康检查
4、MHA 切换测试（手动 + 自动）
测试摘要：
1、传递公钥的用户都需要设置密码且与 MySQL 用户要同一组
2、传递公钥的用户要有 sudo 权限且能通过某一端口进行文件的传递
3、传递公钥的用户要有摘除、添加 VIP 的权限，且在线切换的脚本要更改 root 为传递公钥的用户
4、MHA 的配置文件、目录的属主属组要更改为传递公钥的用户而不是 root 用户
测试的具体搭建过程：
一、配置 MHA 复制集
1、MHA 各角色和 IP 划分
MHA-Master：172.16.3.190/22，VIP：172.16.3.123/22
MHA-Backup：172.16.3.189/22
MHA-Manager:172.16.3.189/22
2、MHA 的 GTID+Semi-Sync +Slave-parallel
搭建复制集的过程省略，需要注意的问题是 master 必须确保所有的 slave 都能连接，包括切换后新主与旧主之间的同步连接。
GRANT SUPER, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’172.16.%.%’ identified by‘repl’;
2.1、GTID 参数配置
gtid_mode=on // 开启 GTID，否则就是普通的复制类型
enforce_gtid_consistency=true // 强制 GTID 的一致性
log_slave_updates=true //slave 更新是否记录日志
master_info_repository=table // 将日志存储为表形式，更加安全，防止日志信息破损
relay_log_info_repository=table // 将日志存储为表形式，更加安全，防止日志信息破损
2.2、Semi-Sync 配置
1、在 MHA 的 master 上安装半同步插件并开启半同步功能
mysql> install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
mysql> install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
mysql> set global rpl_semi_sync_master_enabled=on ;
.2、在 MHA 的 slave 或者 manager 节点上安装插件并开启 slave 的半同步
mysql> install plugin rpl_semi_sync_master soname ‘semisync_master.so’;
mysql> install plugin rpl_semi_sync_slave soname ‘semisync_slave.so’;
mysql> set global rpl_semi_sync_slave_enabled=on ;
3、Slave-paralle 配置
在 MySQL 实例的配置文件中都添加 slave_parallel_workers=N，此处根据机器的配置使用了 4 个应用线程
二、安装 MHA 及基本环境配置
1、在所有的节点上安装 node 数据包，在 manager 节点上安装 manager 数据包
2、编辑 /etc/hosts 文件，添加如下几行内容，指定各机器在 MHA 的角色。
#mha config
172.16.3.190 mha_master
172.16.3.189 mha_backup
172.16.3.189 mha_manager
3、给传递公钥、配置 SSH 登录使用的端口，编辑 SSH 服务的 server 端、client 端的配置文件，分别是 /etc/ssh/sshd_config、/etc/ssh/ssh_config，修改如下行的端口为 22222。server 端的配置文件不要修改行 PermitRootLogin no 为 yes，区别于传统的搭建方法，不是用 root 账号登录。
Port 22222 #此处端口配置为传递互信使用的端口，预传递公钥的端口是多少这里修改为多少。
4、给传递公钥的用户设置密码，这里我们使用的就是 mysql 用户，如果使用其他用户还需要将这个配置互信使用的用户加入到 mysql 用户组；这个用户还需要有 sudo 权限，因为 MHA 的切换过程中有 VIP 的摘除和添加过程，这个步骤要有类似 root 的权限进行操作，且每台机器上都要执行。
## Allow root to run any commands anywhere
root ALL=(ALL) ALL
liyingxiao ALL=NOPASSWD: ALL
mysql ALL=NOPASSWD: ALL
5、切换用户模式为 mysql 并配置机器之间的互信，可以通过 id username 判断用户行为是否是传递公钥使用的用户 mysql
#mha_master 上配置到 mha_backup、mha_manager 的无密码登录
[root@172-16-3-190 we_ops_admin]# su – mysql
[mysql@172-16-3-190 ~]$ ssh-keygen -t rsa
[mysql@172-16-3-190 home]$ cd /home/mysql/.ssh/[mysql@172-16-3-190 .ssh]$ cat id_rsa.pub >> authorized_keys #这里角色复用，因此需要允许多角色自身登录
[mysql@172-16-3-190 .ssh]$ chmod 700 /home/mysql/.ssh/
[mysql@172-16-3-190 .ssh]$ chmod 600 /home/mysql/.ssh/authorized_keys
[mysql@172-16-3-190 .ssh]$ ssh-copy-id -i id_rsa.pub ‘-p22222 mysql@172.16.3.189’
#mha_backup、mha_manager 配置到 mha_master 的无密码登录
[mysql@172-16-3-189 .ssh]$ id
uid=502(mysql) gid=502(mysql) groups=502(mysql)
[mysql@172-16-3-189 .ssh]$ ssh-keygen -t rsa
[mysql@172-16-3-189 ~]$ cd /home/mysql/.ssh/
[mysql@172-16-3-189 .ssh]$ cat id_rsa.pub >> authorized_keys
[mysql@172-16-3-189 .ssh]$ chmod 700 /home/mysql/.ssh/
[mysql@172-16-3-189 .ssh]$ chmod 600 /home/mysql/.ssh/authorized_keys
[mysql@172-16-3-189 .ssh]$ ssh-copy-id -i id_rsa.pub ‘-p22222 mysql@172.16.3.190’
6、验证互信，无密码远程登录其他机器
#172.16.3.190 验证互信
[mysql@172-16-3-190 .ssh]$ ssh mha_backup
[mysql@172-16-3-190 .ssh]$ ssh mha_manager
#172.16.3.189 验证互信
[mysql@172-16-3-189 .ssh]$ ssh mha_master
[mysql@172-16-3-189 .ssh]$ ssh mha_backup
[mysql@172-16-3-189 .ssh]$ ssh mha_manager
7、配置 manager 节点的服务
7.1 创建 manager 节点的监控用户，确保从 manager 节点可以连接 master、slave
mysql> grant all privileges on *.* to ‘mha_monitor’@’172.16.%.%’ identified by ‘mha_monitor’;
Query OK, 0 rows affected, 1 warning (10.12 sec)
7.2 编辑 MHA 的配置文件，以及建立对应的工作目录，并将这些目录的属主属组更改为 MySQL。如果不做更改 SSH/ 同步检查不会报错，但使用其他命令和切换会报权限错误，建议更改属主属组便于后续的维护配置。
[root@172-16-3-189 ~] mkdir ‐p /etc/masterha
[root@172-16-3-189 masterha]# mkdir -p /var/log/masterha/app_3306
[root@172-16-3-189 masterha]# mkdir /opt/shells/masterha
[root@172-16-3-189 we_ops_admin]# chown -R mysql:mysql /var/log/masterha/
[root@172-16-3-189 masterha]# chown -R mysql:mysql /etc/masterha/
[root@172-16-3-189 masterha]# chown -R mysql:mysql /opt/shells/masterha/
[root@172-16-3-189 masterha]# cat /etc/masterha/app_3306.cnf #编辑 MHA 的配置文件
[root@172-16-3-189 masterha]# cat app_3306.cnf
[server default]
# mysql user and password
user=mha_monitor
password=mha_monitor
repl_user=repl
repl_password=repl
ssh_user=mysql
ssh_port=22222
# working directory on the manager
manager_workdir=/var/log/masterha/app_3306
# working directory on MySQL servers
remote_workdir=/var/log/masterha/app_3306
ping_interval=1
master_ip_failover_script=/opt/shells/masterha/master_ip_failover_3306
master_ip_online_change_script=/opt/shells/masterha/master_ip_online_change_script_3306
[server1]
hostname=172.16.3.190
port=3306
master_binlog_dir=/opt/app/mysql_3306/data
[server2]
hostname=172.16.3.189
port=3306
master_binlog_dir=/opt/app/mysql_3306/data
7.3 编辑自动漂移和手动漂移的脚本文件并授予可执行权限，以及 VIP 漂移处给予 sudo 的权限，这里将用户设置为可 sudo，是给予摘除和添加 VIP 的权限
[root@172-16-3-189 we_ops_admin]# chmod +x /opt/shells/masterha/master_ip_failover_3306
[root@172-16-3-189 we_ops_admin]# chmod +x /opt/shells/masterha/master_ip_online_change_script_3306
编辑脚本文件 master_ip_failover_3306，修改如下行为：
my $ssh_start_vip = “sudo /sbin/ifconfig eth0:$key $vip;sudo /sbin/arping -I eth0:0 -c 5 -s 172.16.3.123 172.16.0.1 >/dev/null 2>&1”
编辑 master_ip_online_change_script_3306 修改如下行为：
my $ssh_start_vip = “sudo /sbin/ifconfig eth0:$key $vip;sudo /sbin/arping -I eth0:0 -c 5 -s 172.16.3.123 172.16.0.1 >/dev/null 2>&1”
`ssh mysql\@${new_master_host} \” $ssh_start_vip \”`; #将 root 用户替换为 MySQL 用户，这里会进行 SSH 添加 VIP
`ssh mysql\@${orig_master_host} \” $ssh_stop_vip \”`; #讲 root 用户替换为 MySQL 用户，这里会进行 SSH 摘除 VIP
三、MHA 健康检查（传递公钥的用户模式下进行检查）
1、检查 SSH 免密码登录
[mysql@172-16-3-189 ~]$ masterha_check_ssh –conf=/etc/masterha/app_3306.cnf
2、检查同步状态
[mysql@172-16-3-189 ~]$ masterha_check_repl –conf=/etc/masterha/app_3306.cnf
3、检查 manager 自动漂移服务是否开启
[mysql@172-16-3-189 ~]$ masterha_check_status –conf=/etc/masterha/app_3306.cnf
四、切换测试（漂移过程及结果不做赘述，传递公钥的用户模式下进行漂移）
1、手动切换，并检查同步状态是否正常
[mysql@172-16-3-189 ~]$ masterha_master_switch –conf=/etc/masterha/app_3306.cnf –master_state=alive –orig_master_is_new_slave -interactive=0
2、自动切换，并查看 VIP 是否成功漂移
关闭 master 实例，发现 VIP 成功从 master 摘除并漂移到 slave 上
五、遇到的问题总结
1、MHA 的工作目录公钥用户对此没有权限
2、摘除、添加 VIP 需要有 sudo 权限
3、在线切换的用户要使用公钥用户而不是不用的 root 用户
4、手动切换的过程中，使用公钥用户进行，不必进行 sudo - s 给予 sudo 权限，否则会多余输入密码
：
