MHA搭建及故障维护的方法是什么

67次阅读
没有评论

共计 8780 个字符,预计需要花费 22 分钟才能阅读完成。

本篇内容主要讲解“MHA 搭建及故障维护的方法是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让丸趣 TV 小编来带大家学习“MHA 搭建及故障维护的方法是什么”吧!

(一)环境介绍
1. 主机部署

CentOS 7 改主机名

hostnamectl set-hostname master
192.168.56.121 master
192.168.56.122 slave1 # 备用 master
192.168.56.123 slave2 
192.168.56.124 manager

将 ip 和域名配置到 /etc/hosts 文件中

尝试在各主机上的防火墙上加上端口的允许

iptables -I INPUT -s 0/0 -p tcp --dport 3306 -j ACCEPT

这条规则的意思是,想要在输入数据 INPUT 中,protocol 为 tcp/IP 的方式,访问端口 3306,都会被允许的

iptables -L -n|grep 3306
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306

(二)用 ssh-keygen 实现四台主机之间相互免密钥登录
1. 生成密钥

[master,slave1,slave2,manager]

ssh-keygen -t rsa

[slave1,slave2,manager]

scp .ssh/id_rsa.pub master:/root/.ssh/slave1.pub 
scp .ssh/id_rsa.pub master:/root/.ssh/slave2.pub
scp .ssh/id_rsa.pub master:/root/.ssh/manager.pub

2. 在主机上用 cat xxx authorized_keys 导入公钥到 /root/.ssh/authorized_keys 文件中

[master]

cat ~/.ssh/*.pub ~/.ssh/authorized_keys
scp ~/.ssh/authorized_keys slave1:/root/.ssh/authorized_keys 
scp ~/.ssh/authorized_keys slave2:/root/.ssh/authorized_keys 
scp ~/.ssh/authorized_keys manager:/root/.ssh/authorized_keys

(三)安装 MHAmha4mysql-node,mha4mysql-manager 软件包
1. 安装 MHAmha4mysql-node

[manager,master,slave1,slave2]
yum -y install perl-DBD-MySQL
yum -y install perl-Config-Tiny 
yum -y install perl-Log-Dispatch 
yum -y install perl-Parallel-ForkManager
mha4mysql-node-0.55-0.el6.noarch.rpm

2. 安装 mha4mysql-manager

[manager]
 yum -y install perl
 yum -y install cpan
 rpm -ivh mha4mysql-manager-0.55-0.el6.noarch.rpm

缺啥,yum install xxx 啥就行。

(四)、建立 master,slave1,slave2 之间主从复制

(五)、管理机 manager 上配置 MHA 文件

[manager]

1. 创建目录

mkdir -p /masterha/app1
mkdir /etc/masterha
vi /etc/masterha/app1.cnf
[server default]
user=root
password=root
manager_workdir=/masterha/app1
manager_log=/masterha/app1/manager.log
remote_workdir=/masterha/app1
ssh_user=root
repl_user=rep
repl_password=repl
ping_interval=1
[server1]
hostname=192.168.56.122
master_binlog_dir=/var/lib/mysql
candidate_master=1
#relay_log_purge=0
[server2]
hostname=192.168.56.121
master_binlog_dir=/var/lib/mysql
candidate_master=1
[server3]
hostname=192.168.56.123
master_binlog_dir=/var/lib/mysql
no_master=1
#relay_log_purge=0

(六)、masterha_check_ssh 工具验证 ssh 信任登录是否成功

[manager]
masterha_check_ssh --conf=/etc/masterha/app1.cnf
[root@manager ~]# masterha_check_ssh --conf=/etc/masterha/app1.cnf
Thu Feb 23 12:00:24 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Feb 23 12:00:24 2017 - [info] Reading application default configurations from /etc/masterha/app1.cnf..
Thu Feb 23 12:00:24 2017 - [info] Reading server configurations from /etc/masterha/app1.cnf..
Thu Feb 23 12:00:24 2017 - [info] Starting SSH connection tests..
Thu Feb 23 12:00:25 2017 - [debug] 
Thu Feb 23 12:00:24 2017 - [debug] Connecting via SSH from root@192.168.56.122(192.168.56.122:22) to root@192.168.56.121(192.168.56.121:22)..
Thu Feb 23 12:00:25 2017 - [debug] ok.
Thu Feb 23 12:00:25 2017 - [debug] Connecting via SSH from root@192.168.56.122(192.168.56.122:22) to root@192.168.56.123(192.168.56.123:22)..
Thu Feb 23 12:00:25 2017 - [debug] ok.
Thu Feb 23 12:00:25 2017 - [debug] 
Thu Feb 23 12:00:25 2017 - [debug] Connecting via SSH from root@192.168.56.121(192.168.56.121:22) to root@192.168.56.122(192.168.56.122:22)..
Warning: Permanently added  192.168.56.121  (ECDSA) to the list of known hosts.
Thu Feb 23 12:00:25 2017 - [debug] ok.
Thu Feb 23 12:00:25 2017 - [debug] Connecting via SSH from root@192.168.56.121(192.168.56.121:22) to root@192.168.56.123(192.168.56.123:22)..
Thu Feb 23 12:00:25 2017 - [debug] ok.
Thu Feb 23 12:00:26 2017 - [debug] 
Thu Feb 23 12:00:25 2017 - [debug] Connecting via SSH from root@192.168.56.123(192.168.56.123:22) to root@192.168.56.122(192.168.56.122:22)..
Warning: Permanently added  192.168.56.123  (ECDSA) to the list of known hosts.
Thu Feb 23 12:00:26 2017 - [debug] ok.
Thu Feb 23 12:00:26 2017 - [debug] Connecting via SSH from root@192.168.56.123(192.168.56.123:22) to root@192.168.56.121(192.168.56.121:22)..
Thu Feb 23 12:00:26 2017 - [debug] ok.
Thu Feb 23 12:00:26 2017 - [info] All SSH connection tests passed successfully.
[root@manager ~]#

(七)、masterha_check_repl 工具验证 mysql 复制是否成功

[manager]
masterha_check_repl --conf=/etc/masterha/app1.cnf
[root@manager mysql]# masterha_check_repl --conf=/etc/masterha/app1.cnf
Thu Feb 23 14:37:05 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Thu Feb 23 14:37:05 2017 - [info] Reading application default configurations from /etc/masterha/app1.cnf..
Thu Feb 23 14:37:05 2017 - [info] Reading server configurations from /etc/masterha/app1.cnf..
Thu Feb 23 14:37:05 2017 - [info] MHA::MasterMonitor version 0.55.
Thu Feb 23 14:37:05 2017 - [info] Dead Servers:
Thu Feb 23 14:37:05 2017 - [info] Alive Servers:
Thu Feb 23 14:37:05 2017 - [info] master(192.168.56.121:3306)
Thu Feb 23 14:37:05 2017 - [info] slave1(192.168.56.122:3306)
Thu Feb 23 14:37:05 2017 - [info] slave2(192.168.56.123:3306)
Thu Feb 23 14:37:05 2017 - [info] Alive Slaves:
....... 此处省 
Thu Feb 23 14:37:08 2017 - [info] Connecting to root@192.168.56.123(slave2:22).. 
Creating directory /masterha/app1.. done.
 Checking slave recovery environment settings..
 Opening /var/lib/mysql/relay-log.info ... ok.
 Relay log found at /tmp, up to mysql-relay-bin.000004
 Temporary relay log file is /tmp/mysql-relay-bin.000004
 Testing mysql connection and privileges..Warning: Using a password on the command line interface can be insecure.
 done.
 Testing mysqlbinlog output.. done.
 Cleaning up test file(s).. done.
Thu Feb 23 14:37:08 2017 - [info] Slaves settings check done.
Thu Feb 23 14:37:08 2017 - [info] 
master (current master)
 +--slave1
 +--slave2
Thu Feb 23 14:37:08 2017 - [info] Checking replication health on slave1..
Thu Feb 23 14:37:08 2017 - [info] ok.
Thu Feb 23 14:37:08 2017 - [info] Checking replication health on slave2..
Thu Feb 23 14:37:08 2017 - [info] ok.
Thu Feb 23 14:37:08 2017 - [warning] master_ip_failover_script is not defined.
Thu Feb 23 14:37:08 2017 - [warning] shutdown_script is not defined.
Thu Feb 23 14:37:08 2017 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.

(八)、启动 MHA manager, 并监控日志文件

[manager]
masterha_manager --conf=/etc/masterha/app1.cnf 
tail -f /masterha/app1/manager.log

(九)测试 master(宕机后,是否会自动切换
1. 停掉 master 上的 mysql 服务

[master]
[root@master ~]# service mysql stop
Shutting down MySQL..... SUCCESS! 
[root@master ~]# 
[manager]

2. 宕掉 master 后,/masterha/app1/manager.log 文件显示:

tail -f /masterha/app1/manager.log

日志文件显示:

----- Failover Report -----
app1: MySQL Master failover master to slave1 succeeded
Master master is down!
Check MHA Manager logs at manager:/masterha/app1/manager.log for details.
Started automated(non-interactive) failover.
The latest slave slave1(192.168.56.122:3306) has all relay logs for recovery.
Selected slave1 as a new master.
slave1: OK: Applying all logs succeeded.
slave2: This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
slave2: OK: Applying all logs succeeded. Slave started, replicating from slave1.
slave1: Resetting slave info succeeded.
Master failover to slave1(192.168.56.122:3306) completed successfully.

上面的结果表明 master 成功切换。

切换过程中需要关注的几个问题

1. 切换过程会自动把 read_only 关闭

2. 切换之后需要删除手工删除 /masterha/app1/app1.failover.complete,才能进行第二次测试

3. 一旦发生切换管理进程将会退出,无法进行再次测试,需将故障数据库加入到 MHA 环境中来

4. 原主节点重新加入到 MHA 时只能设置为 slave, 在

change master to master_host= 192.168.56.122 ,
master_user= repl ,
master_password= repl ,
master_log_file= mysql-bin.000010 ,
master_log_pos=120;

之前需要先 reset slave

5. 关于 ip 地址的接管有几种方式,这里采用的是 MHA 自动调用 IP 别名的方式,好处是在能够保证数据库状态与业务 IP 切换的一致性。启动管理节点
VIP 会自动别名到当前主节点上,Keepalived 也只能做到对 3306 的健康检查,但是做不到比如像 MySQL 复制中的 Slave-SQL、
Slave-IO 进程的检查,容易出现对切换的误判。

6. 注意:二级从服务器需要将 log_slave_updates 打开

7. 手工切换需要先定义好 master_ip_online_change_script 脚本, 不然只会切换 mysql,IP 地址不会绑定上去,可以根据模板来配置该脚本

8. 通过设置 no_master= 1 可以让某一个节点永远不成为新的主节点

恢复集群运行

①在 manager 上删除 app1.failover.complete 文件

cd /masterha/app1
rm -f app1.failover.complete

②原 master 主节点服务启动

service mysql start

③ manager 管理节点,检查同步报错

masterha_check_repl --conf=/etc/masterha/app1.cnf
Thu Feb 23 15:00:56 2017 - [error][/usr/share/perl5/vendor_perl/MHA/ServerManager.pm, ln604] There are 2 non-slave servers! MHA manages at most one non-slave server. Check configurations.

⑤查看现在的 slave1 上的信息

mysql  show master status\G
*************************** 1. row ***************************
 File: mysql-bin.000010
 Position: 120
 Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 
1 row in set (0.00 sec)

④配置 187 节点 mysql 为新的 slave,并启动同步进程

change master to master_host= 192.168.56.122 ,
master_user= repl ,
master_password= repl ,
master_log_file= mysql-bin.000010 ,
master_log_pos=120;
mysql  start slave;

再次在管理节点上检查同步状态成功:

masterha_check_repl --conf=/etc/masterha/app1.cnf

需注意:按如上步骤操作后,此时 121 节点作为 slaver 已加入到集群中,但是宕机这段时间 122、123 中新产生的数据在 121 中没有,所以还需要先从主节点备份导入最新的数据再启动同步

⑤启动 MHA
nohup masterha_manager –conf=/etc/masterha/app1.cnf /mha/app1/mha_manager.log 1

回切:
同样的道理,以上步骤配置无问题的话停止当前 master 的 MySQL 进程,MHA 可直接切换 master 至原节点

到此,相信大家对“MHA 搭建及故障维护的方法是什么”有了更深的了解,不妨来实际操作一番吧!这里是丸趣 TV 网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-24发表,共计8780字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)