目录
1.部署
1.1所有节点设置软连接
主节点192.168.222.131，从节点192.168.222.132和192.168.222.133，192.168.222.133同时作为管理节点。软连接是为了契合 MHA 软件，因为传统MHA在启动后，不会加载环境变量profile
ln -s /data/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /data/mysql/bin/mysql /usr/bin/mysql
#MHA架构理想服务器数量是5台，1主2从+1manager+1binlog server
1.2配置主节点与其他节点互信
保证每个Node彼此之间能够互相链接
rm -rf /root/.ssh
ssh-keygen
cd /root/.ssh
mv id_rsa.pub authorized_keys
scp -r /root/.ssh 192.168.222.132:/root
scp -r /root/.ssh 192.168.222.133:/root
各节点互信验证（各节点依次对所有节点执行，包括本身）
ssh 192.168.222.131 date
ssh 192.168.222.132 date
ssh 192.168.222.133 date
1.3主节点创建 mha 专用管理用户
grant all privileges on *.* to mha@'192.168.222.%' identified by 'mha';
1.4下载mha软件：node+manager
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads
manager包： mha4mysql-manager-0.56-0.el6.noarch.rpm
node包： mha4mysql-node-0.56-0.el6.noarch.rpm
MHA软件构成
Manager工具包主要包括以下几个工具：
masterha_manger 启动MHA
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_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_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
1.5安装
所有节点必须安装Node软件依赖包
yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm
管理节点必须安装Manager软件
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.6管理节点创建相关文件目录
mkdir -p /etc/mha
mkdir -p /var/log/mha/app1
1.7管理节点编辑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
#master_ip_failover_script=/usr/local/bin/master_ip_failover
#report_script=/usr/local/bin/send
[server1]
hostname=192.168.222.131
port=3306
[server2]
hostname=192.168.222.132
port=3306
#candidate_master=1
#check_repl_delay=0
[server3]
hostname=192.168.222.133
port=3306
#[binlog1]
#no_master=1
#hostname=192.168.222.133
#master_binlog_dir=/data/mysql/binlog
1.8管理节点互信检查与主从状态检查
masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf
1.9管理节点开启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.10查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf
mysql -umha -pmha -h 192.168.222.131 -e "show variables like 'server_id'"
mysql -umha -pmha -h 192.168.222.132 -e "show variables like 'server_id'"
mysql -umha -pmha -h 192.168.222.133 -e "show variables like 'server_id'"
2.MHA的 vip 功能
对外服务的虚拟IP，当Master宕机之后故障转移过程中选举了新的Master时虚拟IP也会漂移到新Master上，确保服务不会中断。
事先准备好脚本文件master_ip_failover，修改内容以及添加权限
vi /usr/local/bin/master_ip_failover
my $vip = '192.168.222.135/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
注意：master_ip_failover含有中文字符时，dos2unix命令可把中文字符转为英文字符
[root@db03 ~]# yum install -y dos2unix
[root@db03 ~]# dos2unix /usr/local/bin/master_ip_failover
dos2unix: converting file /usr/local/bin/master_ip_failover to Unix format ...
[root@db03 ~]# chmod +x /usr/local/bin/master_ip_failover
添加到manager配置文件:
vi /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover
主节点，手工生成第一个vip地址（重要，不能忘记）
[root@db01 ~]#ifconfig eth0:1 192.168.222.135/24
重启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 &
3.故障提醒
事先准备好邮件脚本文件
添加到manager配置文件
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/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 &
4.binlog server
理想情况下这是一个单独存放拷贝主库binlog的服务器，不会参与任何业务处理，并且不会与主库的binlog产生任何延迟，具体思路是当主库的事务准备提交前，会将binlog记录发送给该服务器，只有当二进制日志存储服务器将该条记录成功存储后，主库上这一事务方可被提交，由此可见，这种技术是在牺牲性能的前提下保证了数据的一致性，一般来说我们都会进行开启，在主机宕机且SSH不可被链接状态下，从库的数据恢复依然可以从二进制日志存储服务器中获取数据。
找一台额外的机器，数据库版本相同，支持gtid并开启
修改manager配置文件，添加如下：
vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=192.168.222.133
master_binlog_dir=/data/mysql/binlog
创建相关目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
拉取主库binlog日志
show slave status\G;
cd /data/mysql/binlog
mysqlbinlog -R --host=192.168.222.131 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
重启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 &
5.故障处理流程
5.1监控到宕机，收到邮件
故障切换是否成功：观察 manager 日志，末尾显示 successfully 则成功
tail -f /var/log/mha/app1/manager
5.2选择新主，配置文件+脚本处理
5.3数据补偿
（1）可连接原主：manage通过save_binary_logs，计算各个从库（包括新主库）与原主库之间binlog差异，将原主库的binlog位置找出来并进行截取、分发到各个从库上进行数据对齐，确保数据一致性；
（2）不能连接原主：manage通过apply_diff_relay_logs，计算各个从库relay-log的差异，将差异较大的从库与新主库进行relay-log对齐，确保数据一致性；
（3）当所有库的数据一致性被确保之后，所有从库都将会与新主库建立主从关系，同时原主库信息将会从Manager项目配置文件中移除，至此整个MHA软件服务结束，Manager不会再对Node进行管理；
（4）二次数据补偿：通过binlog server复制的binlog实现
5.4新从库重新构建主从
(stop slave;
reset slave all;)
(grep "CHANGE MASTER TO" /var/log/mha/app1/manager;)
change master to ...
5.5重新恢复binlogserver
(show slave status\G;)
cd /data/mysql/binlog
rm -rf /data/mysql/binlog/*
mysqlbinlog -R --host=192.168.222.132 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
5.6修改管理节点配置文件，添加原主节点
[server1]
hostname=192.168.222.131
port=3306
5.7重新开启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 &
查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf
5.8扩展：故障节点自愈--待开发
6.注释以及注意事项
6.1 manager 相关文件目录
mkdir -p /etc/mha
#创建manager配置文件目录，可自定义
mkdir -p /var/log/mha/app1
#创建日志目录，可自定义，app1可与业务挂钩，监控多业务可创建多目录，manager可管理多套应用，及多配置文件--多工作目录--多数据目录
6.2 manager 配置文件
[server default]
manager_log=/var/log/mha/app1/manager
#运行过程的日志
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
#主库binlog位置点，所有主从节点binlog必须打开，且最好路径一样
user=mha
password=mha
ping_interval=2
#设置监控主库，发送ping包的时间间隔，尝试三次没有回应时自动进行failover
repl_password=123
repl_user=repl
ssh_user=root
#设置互信的用户
#master_ip_failover_script=/usr/local/bin/master_ip_failover
#MHA 的vip功能
#report_script=/usr/local/bin/send
#故障时邮件提醒的脚本名称
[server1]
#节点标签
hostname=192.168.222.131
port=3306
[server2]
hostname=192.168.222.132
port=3306
#candidate_master=1
#节点设定了权重（candidate_master=1），权重节点会优先选择。
#应用场景：MHA+keepalive VIP(早期MHA架构)；多地多中心
#check_repl_delay=0
#关闭日志量的检查。 MHA 默认评估当节点日志量落后主库100M日志的话，
#即使设定了权重也不会被选择。candidate_master=1可以配合
#check_repl_delay=0，关闭日志量的检查，强制选择候选节点。
#算法选主顺序：是否有强制选主和跳过日志量检查--日志量--配置文件顺序
[server3]
hostname=192.168.222.133
port=3306
#[binlog1]
#binlogserver标签
#no_master=1
#不参与选主，即使是其中一个节点
#hostname=192.168.222.134
#binlog1的地址
#master_binlog_dir=/data/mysql/binlog
#存放主库binlog的目录，注意不能与基本配置中的master_binlog_dir一致
6.3.开启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 &
--remove_dead_master_conf
#主库宕机，自动把故障节点从配置文件去掉
--ignore_last_failover
#忽略最后一次切换。masterha的自我保护机制，两次切换的时间不能超过8（？）小时
/var/log/mha/app1/manager.log
# manager 启动过程中记录日志的文件名
6.4 VIP 功能
vi /usr/local/bin/master_ip_failover
my $vip = '10.0.0.55/24';
#设置vip地址，该地址必须是对外提供服务的网段地址但未使用的空闲地址，24表示子网掩码24位，地址根据生产环境改动
my $key = '1';
#自定义，必须没有占用
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
#生成vip地址，网卡名eth0根据生产环境改动
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
#vip地址下线，网卡名eth0根据生产环境改动
6.5 binlogserver 拉取主库binlog日志
show slave status\G;
#进入SLAVE1或者SLAVE2上，查看一下当前MASTER正在使用的binlog文件
cd /data/mysql/binlog
#必须进入到自己创建好的目录
mysqlbinlog -R --host=192.168.222.131 --user=mha --password=mha --raw --stop-never mysql-bin.000001 &
#注意：拉取日志的起点,需要按照目前从库的已经获取到的二进制日志点为起点
（拉取日志的起点,需要按照目前主库正在使用的binlog为起点）
7.DBA在高可用架构维护的职责
--架构搭建：MHA+VIP+SendReport+BinlogServer
--监控及故障处理
--高可用架构的优化
核心是：尽可能降低主从的延时，让MHA花在数据补偿上的时间尽量减少;
开启GTID模式，开启从库SQL并发复制(slave-parallel-workers=5?)。
1657
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
