MySQL MHA高可用集群部署及故障切换 _集群部署

与天地兮比寿，与日月兮齐光。这篇文章主要讲述MySQL MHA高可用集群部署及故障切换相关的知识，希望能为你提供帮助。
一、MHA概念MHA（MasterHigh Availability）是一套优秀的mysql高可用环境下故障切换和主从复制的软件。
MHA 的出现就是解决MySQL 单点的问题。
MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作。
MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。
1、MHA 的组成
●MHA Node（数据节点）
MHA Node 运行在每台 MySQL 服务器上。
●MHA Manager（管理节点）
MHA Manager 可以单独部署在一台独立的机器上，管理多个 master-slave 集群；也可以部署在一台 slave 节点上。
MHA Manager 会定时探测集群中的 master 节点。当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。
2、MHA 的特点
●自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据不丢失
●使用半同步复制，可以大大降低数据丢失的风险，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性
●目前MHA支持一主多从架构，最少三台服务，即一主两从
二、搭建MySQL+MHA实验思路
1、MHA架构
数据库安装
一主两从
MHA搭建
2、故障模拟
模拟主库失效
备选主库成为主库
原故障主库恢复重新加入到MHA成为从库
实验环境、安装包

主机	操作系统	IP地址	安装包 / 软件 / 工具
MHAmanager	CentOS7-3	192.168.184.10	MHAnode组件、MHAmanager组件
mysql1	CentOS7-3	192.168.184.20	mysql-boost-5.7.20.tar.gz、MHAnode组件
mysql2	CentOS7-3	192.168.184.30	mysql-boost-5.7.20.tar.gz、MHAnode组件
mysql3	CentOS7-3	192.168.184.40	mysql-boost-5.7.20.tar.gz、MHAnode组件

netstat -natp | grep 3306

文章图片

2、修改 master（192.168.184.20）、Slave1（192.168.184.30）、Slave2（192.168.184.40）节点的主机名

hostnamectl set-hostname mysql1
su -

hostnamectl set-hostname mysql2
su -

hostnamectl set-hostname mysql3
su -

文章图片

slave：mysql2(192.168.184.30)、mysql3(192.168.184.40)

vim /etc/my.cnf
server-id = 30
#server-id = 40mysql3则为40，三台服务器 server-id 不能一样
log_bin = master-bin
relay-log = relay-log-bin
relay-log-index = slave-relay-bin.index

systemctl restart mysqld
ln -s /usr/local/mysql/bin/mysql /usr/sbin/
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

文章图片

5、主从复制验证
在Master创建库

文章图片

3、修改内容如下：（删除原有内容，直接复制并修改vip相关参数，vip自定义）

echo> /usr/local/bin/master_ip_failover

vim /usr/local/bin/master_ip_failover

文章图片

#删除原有内容，直接复制并修改节点服务器的IP地址

文章图片

- -remove_dead_master_conf	该参数代表当发生主从切换后，老的主库的 ip 将会从配置文件中移除。
- -manger_log	日志存放位置。

- -ignore_last_failover：在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover，之所以这样限制是为了避免 ping-pong 效应。该参数代表忽略上次 MHA 触发切换产生的文件，默认情况下，MHA 发生切换后会在日志记目录，也就是上面设置的日志app1.failover.complete文件，下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件，为了方便，这里设置为–ignore_last_failover。

查看 MHA 状态，可以看到当前的 master 是 Mysql1 节点。

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

查看 MHA 日志，也以看到当前的 master 是 192.168.184.20，如下所示。

cat /var/log/masterha/app1/manager.log | grep "current master"

查看 Mysql1 的 VIP 地址 192.168.184.200 是否存在，这个 VIP 地址不会因为 manager 节点停止 MHA 服务而消失。

ifconfig

若要关闭 manager 服务，可以使用如下命令。

masterha_stop --conf=/etc/masterha/app1.cnf
或者可以直接采用 kill 进程 ID 的方式关闭

9、故障模拟
在 manager 节点上监控观察日志记录

tail -f /var/log/masterha/app1/manager.log

在 Master 节点 Mysql1 上停止mysql服务

systemctl stop mysqld

正常自动切换一次后，MHA 进程会退出。HMA 会自动修改 app1.cnf 文件内容，将宕机的 mysql1 节点删除。

查看 mysql2 是否接管 VIP

ifconfig

查看manager节点动态日志

故障切换备选主库的算法：
1、一般判断从库的是从（position/GTID）判断优劣，数据有差异，最接近于master的slave，成为备选主。
【MySQL MHA高可用集群部署及故障切换】2、数据一致的情况下，按照配置文件顺序，选择备选主库。
3、设定有权重（candidate_master=1），按照权重强制指定备选主。
默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重，也会失效。
如果check_repl_delay=0的话，即使落后很多日志，也强制选择其为备选主。
故障修复1、修复master