数据库学习之十三：mysql高可用配置

十3、mysql高可用

一、普通主从复制架构存在的不足

高可用？
业务不间断的工做。
用户的体验不出来业务断点。

普通主从环境，存在的问题：

一、监控的问题：APP应用程序，并不具有监控数据库的功能，没有责任监控数据库是否能链接。
二、选主的问题：
三、failover：VIP漂移，对于应用透明
四、数据补偿

二、企业高可用解决方案：

MMM（过期）

MHA（目前推荐）
PXC、Galera Cluster（出现不少年，企业不多用）
5.7.17 MGR 、Innodb Cluster（将来的趋势，尽早研究）
MySQL NDB Cluster（出现不少年，仍然不完善）
MyCAT 高可用

三、MHA高可用架构部署实战：

3.0 MHA介绍及工做原理

（1）Manager程序负责监控全部已知Node（1主2从全部节点）
（2）当主库发生意外宕机
	（2.1）mysql实例故障（SSH可以链接到主机）
		   0、监控到主库宕机，选择一个新主（取消从库角色，reset slave），选择标准：数据较新的从库会被选择为新主(show slave status\G)
		   一、从库经过MHA自带脚本程序，当即保存缺失部分的binlog
		   二、二号从库会从新与新主构建主从关系，继续提供服务
		   三、若是VIP机制，将vip从原主库漂移到新主，让应用程序无感知
	（2.2）主节点服务器宕机（SSH已经链接不上了）
		   0、监控到主库宕机，尝试SSH链接，尝试失败
		   一、选择一个数据较新的从库成为新主库（取消从库角色 reset slave），判断细节：show slave status\G
		   二、计算从库之间的relay-log的差别，补偿到2号从库
		   三、二号从库会从新与新主构建主从关系，继续提供服务
		   四、若是VIP机制，将vip从原主库漂移到新主，让应用程序无感知
		   五、若是有binlog server机制，会继续将binlog server中的记录的缺失部分的事务，补偿到新的主库

3.一、安装mha node：

依赖包perl-DBD-MySQL ，并在三个节点都安装node软件

MHA高可用架构部署细节:
三台MySQL独立节点实例，主机名、IP、防火墙关闭等
开启1主2从GTID复制结构
关闭各节点relay-log自动删除功能
各节点部署node工具包及依赖包
选择其中一个从节点进行部署manager工具包
各节点ssh秘钥互信配置
配置manager节点配置文件（注意：在数据库中添加mha管理用户和密码）
作ssh互信检查和主从状态检查
开启MHA功能

检查防火墙和enforce开关状况：
iptables -L
getenforce
关闭二进制日志删除功能：relay_log_purge=0;
数据库中全局关闭：set relay_log_purge=0;
检查状态：mysql -e "show variables like '%relay%'";
上传MHA软件，而后解压：unzip mha.zip
#涉及到安装两个软件，node和manager；
依赖包perl-DBD-MySQL ，并在三个节点都安装node软件（三个节点都安装node）
rpm包直接
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

3.二、主库中建立mha管理用户

grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';		(会同步给从库)

3.三、配置软链接

ln -s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql /usr/bin/mysql
#mha小bug只能在/usr/bin下使用

3.四、部署manger节点（建议在从节点db03）

wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-6.repo
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes

3.五、安装 manager软件

rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

3.六、建立Manager必要目录与配置文件（DB03）

mkdir -p /etc/mha
mkdir -p /var/log/mha/app1    ----》能够管理多套主从复制
建立配置文件 (不须要的配置不要留着，注释没用,切换后会重写)
vim /etc/mha/app1.cnf     -----》serverdefault能够独立
[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

[server1]
hostname=10.0.0.51
port=3306

[server2]
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306

3.七、配置互信(全部节点)

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1

ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.51
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.52
ssh-copy-id -i /root/.ssh/id_dsa.pub root@10.0.0.53

测试：ssh 10.0.0.51 date
...

3.八、检测互信

masterha_check_ssh  --conf=/etc/mha/app1.cnf

3.九、检测主从

masterha_check_ssh  --conf=/etc/mha/app1.cnf

3.十、启动MHA manager

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 &

tail -f /var/log/mha/app1/manager

故障演练：

一、宕掉db01主库
/etc/init.d/mysqld stop
二、tail -f /var/log/mha/app1/manager  观察日志变化(实时监控日志)
三、恢复主库运行，从新将db01加入到主从复制关系中
检查状态：
show slave stauts\G;
/etc/init.d/mysqld start
CHANGE MASTER TO MASTER_HOST='10.0.0.52', MASTER_PORT=3306, MASTER_AUTO_POSITION=1, MASTER_USER='repl', MASTER_PASSWORD='123';
start slave;
show slave status\G;
四、将配置文件中加入修稿的故障节点(宕机后自动删除被删除的server信息)
五、启动MHA了manager程序（经历主库宕机后，manager会完成自杀进程的步骤）
 masterha_check_ssh  --conf=/etc/mha/app1.cnf 
 masterha_check_ssh  --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.十一、使用MHA自带脚本实现IP FailOver(vip 漂移，应用透明)
#################################END#########################################

配置步骤

上传准备好的/usr/local/bin/master_ip_failover(脚本文件)
chmod +x master_ip_failover
dos2unix /usr/local/bin/master_ip_failover

vim /etc/mha/app1.cnf
添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover

重启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 &

手工在主库上绑定vip，注意必定要和配置文件中的ethN一致（master_ip_failover），个人是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24

切换测试：
停主库，看vip是否漂移

/etc/init.d/mysqld stop

3.十二、binlogserver配置：

找一台额外的机器，必需要有5.6以上的版本，支持gtid并开启，咱们直接用的第二个slave
vim /etc/mha/app1.cnf（在10.0.0.53机器上）
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog

提早建立好,这个目录不能和原有的binlog一致
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/mysql/*
修改完成后，将主库binlog拉过来（从000001开始拉，以后的binlog会自动按顺序过来）

cd /data/mysql/binlog     -----》必须进入到本身建立好的目录，在主库的/data/binlog目录中查看是不是从如下001开始的。

mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

重启MHA，生效配置：

重启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.1三、其余参数说明
ping_interval=2 manager检测节点存活的间隔时间，总共会探测4次。

设置为候选master，若是设置该参数之后，发生主从切换之后将会将此从库提高为主库，即便这个主库不是集群中事件最新的slave

candidate_master=1

默认状况下若是一个slave落后master 100M的relay logs的话，MHA将不会选择该slave做为一个新的master，

由于对于这个slave的恢复须要花费很长时间，经过设置check_repl_delay=0, MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机很是有用， 由于这个候选主在切换的过程当中必定是新的master check_repl_delay=0