MYSQL高级运用-MHA(提供主从复制高可用,主节点故障时,进行故障转移)

MHA的介绍、重用工具;
MHA的安装;
搭建MYSQL主从复制架构,运用MHA实现其高可用,主节点故障时,进行故障转移;并恢复整个架构;

MHA

MHA(Master HA )是一款开源的MYSQL的高可用程序,它为MYSQL主从复制架构提供了automating master failover 功能。MHA在监控到master节点故障时,会提升其中拥有最新数据的slave节点成为新的master节点,在此期间,MHA会通过于其他从节点获取额外信息来避免一致性方面的问题。MHA还提供了master节点的在线切换功能,即按需切换master/slave节点。
MHA服务有两种角色,MHA Manager(管理节点)和MHA Node(数据节点):
MHA Manager:通常单独部署在一台独立机器上管理多个master/slave集群,每个master/slave集群称作一个application;
MHA node:运行在每台MYSQL服务器上(master/slave/manager),它通过监控具备解析和清理logs功能的脚本来加快故障转移。

MHA组件:

MHA会提供诸多工具程序,其常见的如下所示。

Manager节点:

masterha_check_ssh :MHA依赖的ssh环境监测工具
masterha_check_repl: MYSQL复制环境检测工具;
masterga_manager: MHA 服务主程序
masterha_check_status: MHA 运行状态探测工具;
masterha_master_monitor:MYSQL master节点可用性监测工具;
masterha_master_swith:master节点切换工具;
masterha_conf_host:添加或删除配置的节点;
masterha_stop:关闭MHA服务的工具。

Node节点:

save_binary_logs:保存和复制master的二进制日志;
apply_diff_relay_logs:识别差异的中继日志事件并应用于其他slave;
filter_mysqlbinlog:去除不必要的ROLLBACK事件(MHA已不再使用这个工具
purge_relay_logs:清除中继日志(不会阻塞SQL线程);

自定义扩展:

secondary_check_script:通过多条网络路由检测master的可用性;
master_ip_failover_script:更新application使用的masterip;
report_script:发送报告
init_conf_load_script:加载初始配置参数;
master_ip_online_change_script:更新master节点ip地址;

实验:实现主从复制的高可用,主节点故障时,进行故障转移;以及回复整个复制集群。

1、准备实验MYSQL Replication环境:

MHA对MYSQL复制环境有特殊要求,例如各节点都要开启二进制日志及中继日志,各从节点必须显示启用其read-only属性,并关闭relay_log_purge功能等,这里对配置做事先说明。
本实验环境共有四个节点,其角色分配如下:
node1:MariaDB master
node2: MariaDB slave
node3: MariaDB slave
node4: MHA Manager
各节点的/etc/hosts文件配置内容中添加:
172.16.252.18 node1.magedu.com node1
172.16.252.17 node2.magedu.com node2
172.16.252.20 node3.magedu.com node3
172.16.252.21 node4.magedu.com node4
初始主节点master配置:
[mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON
innodb_file_per_table = ON
所有slave节点依赖的配置:
[mysqld]
server-id = 2 #复制集群中的各节点的id均必须唯一;
relay-log = relay-log
log-bin = master-log
read_only = ON
relay_log_purge = 0
skip_name_resolve = ON
innodb_file_per_table = ON
按上述要求分别配置好主从节点之后,按MYSQL复制配置架构的配置方式将其配置完成并启动master节点和各slave节点,以及为各slave节点启动其IO和SQL线程,确保主从复制运行无误。操作如下:
master节点上:
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON
*.* TO ‘repluser’@172.16.252.%’ IDENTIFIED BY ‘replpass’;
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> SHOW MASTER STATUS;
+——————-+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————-+———-+————–+——————+
| master-log.000003 | 498 | | |
+——————-+———-+————–+——————+
各slave节点上:
[root@node3 ~]# mysql
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST=’172.16.252.18′,MASTER_USER=’repluser’,MASTER_PASSWORD=’replpass’,MASTER_LOG_FILE=’master-log.000003′,MASTER_LOG_POS=498;
MariaDB [(none)]> START SLAVE;
MariaDB [(none)]> SHOW SLAVE STATUS\G
而后,在所有MYSQL节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。当然,此时仅需要且只能在master节点运行类似如下SQL语句即可。
mysql> GRANT ALL ON *.* TO ‘mhaadmin’@’172.16.252.%’ IDENTIFIED BY ‘mhapass’;
各slave节点可以查看:
SHOW GRANTS FOR ‘proxysql’@’172.16.252.%’;1

2、安装配置MHA

a、准备基于SSH互信通信环境
MHA集群中的各节点彼此之间均需要基于ssh互信通信,以实现远程控制及数据管理功能。简单起见,可在Manager节点生成密钥对儿,并设置其可远程连接本地主机后,将私钥文件及authorized_keys文件复制给余下的所有节点即可。
下面操作在node4:Manager 节点上操作:
[root@node4 ~]# ssh-keygen -t rsa -P ”
[root@node4 ~]#ssh-copy-id -i .ssh/id_rsa.pub root@node4
自己连接自己进行验证
2
[root@node4 ~]# for i in {1..3}; do scp -p .ssh/id_rsa .ssh/authorized_keys root@node$i:/root/.ssh/; done
编写一个小循环把.ssh/id_rsa (私钥)、shh/authorized_keys(记录进行公钥认证的信息)复制到三个节点上。复制完成后,各节点可以互信通信连接测试,进行验证。
验证发现各节点之间进行ssh连接时,老是要回答yes:
可以修改/etc/ssh/ssh_config 配置文件:
StrictHostKeyChecking no
或者可以用ssh -o 选项进行参数的传递:
ssh -o StrictHostKetchecking=no node1
b、安装MHA
除了源码包,MHA官方也提供了rpm格式的程序包,其下载地址为:
https://code.google.com/archlve/p/mysql-masterha/wiki/Downloads?tm=2
Centos7系统可直接使用适用于el6的程序包。另外,MHA Manage和MHA Node 程序包的版本并不强制要求一致。
这里我直接在FTP共享里面下载的rpm包:
lftp 172.16.0.1/pub
>cd Sources/6.x86_64/mha
>mget mha4mysql-node-0.56-0.el6.norch.rpm mha4mysql-manager-0.560.el6.noarch.rpm
Manager 节点:
#yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有节点,包括Manager:
#yum install mha4mysql-node-0.56-0.el6.norch.rpm

c、初始化MHA,进行配置

Manager 节点需要为每个监控的master/slave集群提供一个专用的配置文件,而所有的master/slave集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf,其为可选配置。如果仅监控一组master/slave集群,也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义。
例如,本示例中将使用/etc/masterha/app1.cnf,其操作如下:
[root@node4 ~]# mkdir /etc/masterha
[root@node4 ~]# vim /etc/masterha/app1.cnf
[server default]
user=mhaadmin
password=mhaadminpass
manager_workdir=/data/masterha/app1
manager_log=/data/masterha/app1/manager.log
remote_wordir=/data/masterha/app1
ssh_user=root
repl_user=repluser
repl_password=replpass
ping_interval=1
[server1]
hostname=172.16.252.18
candidate_master=1
[server2]
hostname=172.16.252.17
candidate_master=1
[server3]
hostname=172.16.252.20
candidate_master=1
检测各节点间ssh互信通信配置是否Ok:
[root@node4 ~]# master_check_ssh –conf=/etc/masterha/app1.cnf
输出信息最后一行类似如下信息,表示其通过检测。
[info]All SSH connection tests passed successfully.
检查管理的MySQL复制集群的连接配置参数是否OK:
[root@node4 ~]#master_check_repl –conf=/etc/masterha/app1.cnf
测试时会报错:从节点上没有账号,因为这个架构,任何一个从节点,将有可能成为主节点, 所以也需要创建账号。
因此,这里只要在mater节点上再次执行以下操作即可:
MariaDB [(none)]>GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO ‘repluser’@172.16.252.%’ IDENTIFIED BY ‘replpass’;
MariaDB [(none)]> FLUSH PRIVILEGES;
Manager节点上再次运行,就显示Ok了。

d、启动MHA

[root@node4 ~]#nohup masterha_manager –conf=/etc/master/aap1.cnf &> /data/masterha/manager.log &
启动成功后,可用过如下命令来查看master节点的状态:
[root@node4 ~]#masterha_check_status –conf=/etc/master/aap1.cnf
app1 (pid:4978)is running(0:PING_OK),master:172.16.252.18
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服务运行OK,否则,则会显 示为类似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA,需要使用master_stop命令。
[root@node4 ~]#masterha_stop –conf=/etc/masterha/app1.cnf

e 、测试故障转移

(1)在master节点关闭mariadb服务,模拟主节点数据崩溃
#killall -9 mysqld mysqld_safe
#rm -rf /var/lib/mysql/*
(2)在manager节点查看日志:
/data/masterha/app1/manager.log 日志文件中出现如下信息,表示manager检测到172.16.252.18节点故障,而后自动执行故障转移,将172.16.252.17提升为主节点。
注意,故障转移完成后,manager将会自动停止,此时使用masterha_check_status命令检测将会遇到错误提示,如下所示:
#masterha_check_status –conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RINNING).
(3)提供新的从节点以修复复制集群
原有master节点故障后,需要重新准备好一个新的MySQL节点。基于来自于master节点的备份恢复数据后,将其配置为新的master的从节点即可。注意,新加入的节点如果为新增节点,其Ip地址要配置为原来master节点的IP,否则,还需要修改app1.cnf中相应的ip地址。随后再次启动manager,并再次检测其状态。
此时node2为主节点,进行一次完全数据备份:
#mysqldump -x -R –triggers –events –master-data=2 –flush-logs –all-databases > /tmp/alldatabases.sql
#scp /tmp/databases.sql node1:/root/
note1:
#sysytemctl start mariadb.service
#mysql < /root/databases.sql 进行数据重放,还原。
连入mysql发现数据已回复了。
#head -30 alldatabases.sql
CHANGE MASTER to MASTER_LOG_FILE=’master-log.000002′, MASTER_LOG_POS=245; 备份那一刻,日志文件,处于哪个位置.
#mysql
>CHANGE MASTER TO MASTER_HOST=’172.16.0.17′,MASTER_USER=’repluser’,MASTER_PASSWORD=’replpass’,MASTER_LOG_FILE=’master-log.000002′,MASTER_LOG_POS=245;
>START SLAVE;
# vim /etc/my.cnf.d/server.cnf
[mysql]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve = ON
innodb_file_per_table = ON
read_only = ON
#systemctl restart mariadb.service
note4:Manager节点上在次启动,并检测MYSQL复制集群;

本文来自投稿,不代表Linux运维部落立场,如若转载,请注明出处:/87554

发表评论

登录后才能评论

联系我们

400-080-6560

在线咨询:点击这里给我发消息

邮件:1823388528@qq.com

工作时间:周一至周五,9:30-18:30,节假日同时也值班

友情链接:万达娱乐招商  万达娱乐主管QQ  万达开户  测试  万达招商  万达开户  万达娱乐开户  万达招商QQ  万达主管QQ  万达直属QQ