基于MHA的MySQL高可用
一、MHA工作原理以及实验准备1、MHA工作原理总结为以下几条：
（1）从宕机崩溃的master保存二进制日志事件（binlog events）;
（2）识别含有最新更新的slave;
（3）应用差异的中继日志(relay log) 到其他slave;
（4）应用从master保存的二进制日志事件(binlog events);
（5）提升一个slave为新master;
（6）使用其他的slave连接新的master进行复制。
2、本实验环境共需要四个节点，其角色分配如下：
node1：MariaDB master
node2：MariaDB slave
node3：MariaDB slave
node4：MHAmanager
二、实现MySQL的主从
配置MySQL主服务器
1，配置master主服务器 （配置文件）
server-id=1 //配置server-id ，让主服务器又唯一ID号
log-bin=zuozuo-bin//打开二进制日志
relay-log =zuozuo-relay-log // 打开中继日志
log_slave_updates = 1
skip_name_resolve//关闭域名解析
2创建复制账号
在登录MySQL的前提下，在master的数据库下创建一个备份账户，每个slave使用标准的MySQL用户名和密码连接master，进行复制操作的slave会授予replication slave权限
grant replication slave，replicationclient client on . to slave @'172.17.%.%'> 3、配置所有slave节点
server-id =2/配置server-id不可以与master重复
relay-log =zuozuo-relay-log //开启中继日志
log-bin = zuozuo-bin
log_slave_updates = 1 //使得更新的日志写进二进制日志中
read_only=ON //设置制度权限，保证数据库数据的一致性
relay_log_purge=0
skip_name_resolve //忽略域名解析
4、启动从服务器父子线程
让slave连接master，病开始重做master二进制日志中的事件
change master to master_host='172.17.252.157', //master的IP地址
maste_user='slave';
master_password='123456',
master_log_file='zuozuo-bin.000002', //主服务器的二进制日志文件名
master_log_pos=278;//读取二进制文件的起点
执行start slave ；// 启动复制线程
三、准备通信环境
MHA集群中的各个节点之间均需要局域SSH互相通信，以实现远程控制和数据管理功能，简单起见，可在manager节点生成密钥对，实现各节点尖实现基于key的免密码登录。
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
ssh-copy-id -i .ssh/id_rsa.pub@各个MySQL数据库ID
四 、安装配置MHA
1、安装MHA
Manager 节点： #yum install mha4mysql-manager-0.56-0.el6.noarch.rpm
所有节点，包括Manager: #yum install mha4mysql-node-0.56-0.el6.norch.rpm
注：对于manager节点 要先安装mha4mysql-node包然后安装管理包，避免一些依赖包没有安装影响管理包的安装。
在所有MySQL节点授权拥有管理权限的用户可在本地网络紫红有其他节点上远程访问，当然，此时仅需要且只能在master节点上创建并且授权用户；
mysql> GRANT ALL ON *.* TO 'mhaadmin'@'172.17.%.%'>
'mhapass';
2、初始化MHA，进行配置
manager节点需要为每个监控的master/slave集群提供一个专用的配置文件，而所有的master/slave集群也可共享全局配置。全局配置文件默认为/etc/masterha_default.cnf ，其为可选配置。如果仅监控一组master/slave集群，也可直接通过application的配置来提供各服务器的默认配置信息。而每个application的配置文件路径为自定义。
3、定义MHA管理配置文件
mkdir /etc/mha_master
vim /etc/mha_master/app.cnf
user=mhaadmin
password=123456
manager_workdir=/etc/mha_master/app1
manager_log=/etc/mha_master/manager.log
remote_workdir=/mydata/mha_master/app1
ssh_user=root
repl_user=slave
repl_user=slave
ping_interval=1
hostname=172.17.253.21
ssh_port=22
candidate_master=1
hostname=172.17.253.157
ssh_port=22
candidate_master=1
hostname=172.17.253.59
ssh_port=22
candidate_master=1
4、检测各节点间ssh互相通信配置是否OK
# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
输出信息最后一行类似如下信息，表示其通过检测。
All SSH connection tests passed successfully.
#masterha_check_repl -conf=/etc/mha_master/app1.cnf
如果测试时会报错，可能是节点上没有账号，因为这个架构，任何一个从节点，将有可能成为主节点，所以也需要创建账号
五、启动MHA
#nohup masterha_manager -conf=/etc/mha_master/app1.cnf
&> /etc/mha_master/manager.log & //启动之后后台运行，负责将会占住挡墙终端，不能进行之后的操作。
启动成功之后，查看master节点的状态
#masterha_check_status -conf=/etc/mha_master/app1.cnf
如果要停止MHA，需要使用master_stop命令。
#masterha_stop -conf=/etc/mha_master/app1.cnf
六、测试MHA故障转移
(1)在master节点关闭mariadb服务,模拟主节点数据崩溃
systemctl stop mariadb
(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，并再次检测
其状态。
(4)新节点提供后再次执行检查操作
masterha_check_status -conf=/etc/mha_master/app1.cnf
masterha_check_repl -conf=/etc/mha_master/app1.cnf
检查无误，再次运行，这次要记录日志
masterha_manager -conf=/etc/mha_master/app1.cnf
/etc/mha_master/manager.log2>&1
七、新节点上线，故障转换恢复注意事项
(1)、在生产环境中，当你的主节点挂了后，一定要在从节点上做一个备份，拿着备份文件把主节点手动提升为从节点，并指明从哪一个日志文件的位置开始复制
(2)、每一次自动完成转换后，每一次的(replication health )检测不ok始终都是启
动不了必须手动修复主节点，除非你改配置文件
(3)、手动修复主节点提升为从节点后，再次运行检测命令
# masterha_check_repl --conf=/etc/mha_master/app1.cnf
app1 (pid:3211) is running(0:PING_OK), master:172.16.5.103
(4)、再次运行起来就恢复成功了
masterha_manager --conf=/etc/mha_master/app1.cnf
页:
[1]