文章目录
- MHA高可用基础环境搭建：准备主从、部署MHA
- 准备主从
- 开始安装部署MHA：
MHA高可用基础环境搭建：准备主从、部署MHA
-
节点的含义
节点是指每台配备了MHA高可用的机器，英文称为node
-
主节点
拥有master权限的主数据库，被称为主节点（主库）
-
从节点
没有master权限的从数据库，被称为从节点（从库）
准备主从
一、简介与原理
1.简介
-
MHA能够在较短的时间内实现自动故障检测和故障转移，通常在10-30秒以内；在复制框架中，MHA能够很好地解决复制过程中的数据一致性问题，由于不需要在现有的replication中添加额外的服务器，仅需要一个manager（管理节点），而一个Manager能管理多套复制，所以能大大地节约服务器的数量；另外，安装简单，无性能损耗，以及不需要修改现有的复制部署也是它的优势之处。
-
MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。
-
MHA由两部分组成：
-
MHA Manager（管理节点）
-
MHA Node（数据节点）
-
-
MHA Manager可以独立部署在一台独立的机器上管理多个Master-Slave集群，也可以部署在一台Slave上。当Master出现故障时，它可以自动将最新数据的Slave提升为新的Master,然后将所有其他的Slave重新指向新的Master（整个故障转移过程对应用程序是完全透明的）
-
原理：
- 当Master出现故障时
它可以自动将最新数据的Slave提升为新的Master（数据量最接近主库的那台服务器，每台服务器速度不能保证完全一样）
然后将所有其他的Slave重新指向新的Master（如果原主库恢复，只能当从库） - 我们用过其他的高可用keepalived，lb01和lb02，使用的keepalived，但是当vip在一台机器上的时候，另一台机器是闲置的，数据用这种方式的话稍微有点浪费资源
所以mysql有自己的高可用MHA
- 当Master出现故障时
2.MHA工作原理(详解):
1.保存master主库上所有的binlog事件
2.找到数据量最新的数据（通过对比relay-log）
3.将数据最新的从库数据同步至其他从库
4.提升数据最新的从库为主库（这个时候已经可以恢复业务使用数据库了）
5.通过主库保存的binlog补全到新的主库上
6.其他从库开启以数据最新从库为主的主从复制
- PS注意：
- 如果主库是突然断电，机器已经连不上了，怎么保存binlog？
relay-log不是一直存在的，他在一个sql执行完之后会删除？ - 我们使用的时候可以看日志
通过MHA组件：manager 和 node
- 如果主库是突然断电，机器已经连不上了，怎么保存binlog？
二、MHA架构
1.MHA是 C/S 结构的服务，类似于监控
2.MHA manager可以安装在任意一台机器上
3.其他所有机器都要装一个node（节点）
4.MHA manager监控主库的node，从库上的node会在切换时发送一些指令，主库保存binlog的工作，其实就是node节点的作用
5.一个MHA manager可以管理多套mysql主从集群（指定配置文件启动多次就可以，像是多实例）
6.可以在主从运行中添加 MHA
7.MHA 尽量避免装在主库上
8.MHA 通过ssh 去管理的其他节点，先做免密
三、MHA工具介绍
1.manager相关工具
通过解压MHA源码包,了解MHA manager工具
[root@db-01 ~]# tar xf mha4mysql-manager-0.56.tar.gz
[root@db-01 bin]# ll /root/mha4mysql-manager-0.56/bin
#检查replication(主从复制)
masterha_check_repl
#检查ssh(检测免密)
masterha_check_ssh
#检查MHA的启动状态状态
masterha_check_status 等同与 systemctl status mha
#配置主机信息(MHA在切换主库之后，他会提升从库为主库，并且会把主库的信息删除，不论谁是主库都会删除)
masterha_conf_host
[server1]
hostname=10.0.0.51
port=3306
[server2]
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306
#MHA manager启动程序
masterha_manager 等同于 systemctl start mha
#监控主库心跳
masterha_master_monitor
#切换主机
masterha_master_switch
#建立TCP连接
masterha_secondary_check
#停止MHA
masterha_stop 等同于 systemctl stop mha
--------------------------------------------------
#常用：
masterha_check_repl
masterha_check_ssh
masterha_manager
masterha_stop
2. node相关工具
#通过解压MHA源码包,了解MHA node工具
[root@db-01 ~]# tar xf mha4mysql-node-0.56.tar.gz
[root@db-01 bin]# ll /root/mha4mysql-node-0.56/bin
#对比中继日志
apply_diff_relay_logs
#防止binlog回滚 rollback（物理备份的时候会做redo，为了防止数据丢失，切换以后正常使用不能保证客户不会提交）
filter_mysqlbinlog
#删除relay-log ###关闭mysql自动清除relay-log的功能
purge_relay_logs
#保存binlog日志
save_binary_logs
四、MHA优点总结
1.Masterfailover and slave promotion can be done very quickly
自动故障转移快(10-30)
2.Mastercrash does not result in data inconsistency
主库崩溃掉，不会存在数据一致性问题
3.Noneed to modify current MySQL settings (MHA works with regular MySQL)
不需要对当前mysql环境做重大修改
4.Noneed to increase lots of servers
不需要添加额外的服务器(仅一台manager就可管理上百个replication)
5.Noperformance penalty
性能优秀，可工作在半同步复制和异步复制，支持gtid，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
#ping baidu.com 10.0.0.50 (icmp协议)
#发送ping包属于sql ping ， select ping 检测主库的心跳
6.Works with any storage engine
只要replication支持的存储引擎，MHA都支持，不会局限于innodb
五、基于GTID的主从复制
1.什么是GTIDE
1.他是一个全局事务标识符：是一个唯一标识符，他与主库上提交的每个事务相关联
GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。
这种方式强化了数据库的主备一致性，故障恢复以及容错能力。
2.此标识符不仅对其发起的服务器是唯一的，而且在给定复制设置中的所有服务器都是唯一的，所有的事务和所有的GTID都是1对1的映射
3.GTID实际上是由UUID+TID组成的
UUID是数据库实例的标识符
TID表示事务提交的数量，会随着事务的提交递增
具体形式：5426a3c1-ade1-11e9-90b3-000c29bb4490:23
2.GTID优缺点
#GTID优点(新特性):
1.GTID会开启多个SQL线程，每一个库，开启一个SQL线程
2.如果开启row:只保存改变数据的列，节省网络资源，磁盘占用空间和内存使用
3.GTID会把主从相关的信息，记录到表中，增强使用性
4.支持延时复制
5.传统的主从复制，show master status; 记录:binlog_file binlog_pos
基于GTID的主从复制，不需要记录这两个值，直接自动查找
#缺点:
1.mysqldump 备份起来很麻烦，需要额外加参数 --set-gtid=on
2.如果主从复制遇到了错误，SQL停了，跳过错误，GTID无法跳过错误
stop slave;
set global sql_slave_skip_counter=1;
start slave;
#正常的主从，counter=1是跳过一条sql，而GTID是基于事务的主从复制，如果跳过就是跳过一个事务，我得错误语句只是一条SQL错了，是不允许跳过事务的
#网上跳过事务的方法：
1)停止slave进程
mysql> STOP SLAVE;
2)设置事务号，事务号从Retrieved_Gtid_Set获取
在session里设置gtid_next，即跳过这个GTID
mysql> SET GTID_NEXT= '6d257f5b-5e6b-11e8-b668-5254003de1b6:1'
3)设置空事物
mysql> BEGIN; COMMIT;
4)恢复事物号
mysql> SET SESSION GTID_NEXT = AUTOMATIC;
5)启动slave进程
mysql> START SLAVE;
3.GTID主从复制
1）准备三台MySQL机器（一主两从）
| 准备机器 | IP | 内存 | 角色 |
|---|---|---|---|
| db01 | 10.0.0.51 | 2G | 主库，主节点1 |
| db02 | 10.0.0.52 | 2G | 从库，从节点2 |
| db03 | 10.0.0.53 | 2G | 从库，从节点3 |
2）所有机器统一准备环境
1> 关闭防火墙与selinux
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0
2> 安装epel源
若/etc/yum.repos.d/有epel.repo，则无需安装！
[root@localhost ~]# yum install wget -y
[root@localhost ~]# wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
3）配置安装MySQL服务（所有节点：一个主库，两个从库）
1> 配置MySQL的repo源文件
[root@db02 ~]# vim /etc/yum.repos.d/mysql-community.repo
# Enable to use MySQL 5.6
[mysql56-community]
name=MySQL 5.6 Community Server
baseurl=http://repo.mysql.com/yum/mysql-5.6-community/el/6/$basearch/
enabled=1
gpgcheck=0
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
2>安装MySQL服务（所有节点）
[root@db02 ~]# yum install mysql-community-server -y
4）编辑配置文件
- 以下是主从复制、以及MHA高可用的配置文件内容
- 若只部署主从复制，则无需添加下方的MHA高可用配置
- 若后面需安装高可用时，回来追加以下MHA所需的配置即可~
1.主库配置要求:
- 主库id必须与从库不同
- 开启GTID
[root@db-01 ~]# vim /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql # 必配
server_id=1 # 必配，与其他主机不能相同
log-bin=mysql-bin # 必配
########以上是主从复制普通配置#########
######以下是MHA高可用所需附加配置######
binlog_format=row # binlog格式，行
gtid_mode=on # 主从复制更高效
enforce_gtid_consistency # 开启一致性
log-slave-updates # 更新从库的binlog
2.从库配置要求：
- 从库的id虽说可以相同，但最好不同
[root@db-02 data]# vim /etc/my.cnf
[mysqld]
server_id=2 # 必配，且不能相同
########以上是主从复制普通配置#########
######以下是MHA高可用所需附加配置######
log-bin=mysql-bin # 必配，与主库指定相同
gtid_mode=on # 主从复制更高效
enforce_gtid_consistency # 开启一致性
log-slave-updates # 更新从库的binlog
[root@db-03 data]# vim /etc/my.cnf
[mysqld]
server_id=3 # 必配，且不能相同
########以上是主从复制普通配置#########
######以下是MHA高可用所需附加配置######
log-bin=mysql-bin # 必配，与主库指定相同
gtid_mode=on # 主从复制更高效
enforce_gtid_consistency # 开启一致性
log-slave-updates # 更新从库的binlog
PS：binlog-do-db=db01
# 此条配置为过滤复制，配置文件通常用不上，无需配置
# 通常做过滤复制在从库上做，主库上不要配置过滤，会出现不能生成binlog日志的问题!
4.1）启动报错与配置解释
报错：若启动不起来，查看错误日志：需要开启gtid
[root@db-03 ~]# tail -100 /usr/local/mysql/data/db-03.err
[ERROR] --gtid-mode=ON requires --log-bin and --log-slave-updates
[ERROR] Aborting
配置：log-slave-updates
#更新从库的binlog（从库的binlog不会写入，是把数据写到relay-log的，加这个参数会将数据写入binlog）
#有的时候双主也要加这个参数（不推荐使用，浪费资源）
#还有级联复制也要加（主库的从库也是其他主从的主库）
使用log-slave-updates参数的几种情况：
1.GTID
2.双主+KEEPALIVED
3.级联复制
5）主库查看GTID是否开启的命令
mysql> show variables like '%gtid%';
+---------------------------------+-----------+
| Variable_name | Value |
+---------------------------------+-----------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+-----------+
8 rows in set (0.00 sec)
5.1）扩展：GTID的作用
-
优点：GTID相对于行复制数据安全性更高，故障切换更简单
- 根据 GTID 可以快速的确定事务最初是在哪个实例上提交的。
- 简单的实现 failover，不用以前那样在需要找 log_file 和 log_pos。
- 更简单的搭建主从复制，确保每个事务只会被执行一次。
- 比传统的复制更加安全，一个 GTID 在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
-
缺点：
- 1）主从库的表存储引擎必须是一致的：
主从库的表存储引擎不一致，就会导致数据不一致。如果主从库的存储引擎不一致，例如一个是事务存储引擎，一个是非事务存储引擎，则会导致事务和 GTID 之间一对一的关系被破坏，结果就会导致基于 GTID 的复制不能正确运行；
master：对一个innodb表做一个多sql更新的事物，效果是产生一个GTID。
slave：假设对应的表是MYISAM引擎，执行这个GTID的第一个语句后就会报错，因为非事务引擎一个sql就是一个事务。当从库报错时简单的stop slave; start slave;就能够忽略错误。但是这个时候主从的一致性已经出现问题,需要手工的把slave差的数据补上,这里要将引擎调整为一样的，slave也改为事务引擎。
- 2）不允许一个SQL同时更新一个事务引擎和非事务引擎的表
事务中混合多个存储引擎，就会产生多个 GTID。当使用 GTID 时，如果在同一个事务中，更新包括了非事务引擎（如 MyISAM）和事务引擎（如 InnoDB）表的操作，就会导致多个 GTID 分配给了同一个事务。
- 3）在一个复制组中，必须要求统一开启GTID或是关闭GTID;
- 4）不支持create table….select 语句复制（主库直接报错）;
PS：create table xxx as select的语句，其实会被拆分为两部分，create语句和insert语句，但是如果想一次搞定，MySQL会抛出如下的错误：
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.
PS：create table xxx as select 的方式可以拆分成两部分，如下：
create table xxxx like data_mgr;insert into xxxx select *from data_mgr;
6）主库授权主从复制用户并查看master状态
mysql> grant replication slave on *.* to slave'@'172.16.1.5%' identified by '123';
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000010 | 120 | db01 | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
7）从库分别执行 chang master to语句
change master to
master_host='10.0.0.51',
master_user='slave',
master_password='123',
master_log_file='mysql-bin.000010'
master_log_pos=120;
8）从库分别开启IO线程和SQL线程
mysql> start slave;
9）从库分别检查slave状态
mysql> show slave status\G
# 若以下两个状态为Yes，即为成功开启主从复制！
······
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
······
10）主从状态开启失败解决（从库）
- Slave_IO_Running: No
IO线程连接主库失败：
1）检查change语句配置时：user、password、ip、port是否准确
mysql> show slave status\G
Master_Host: 10.0.0.51
Master_User: slave
Master_Port: 3306
······
密码是不显示的，若都没问题，则：
- stop slave
- 重新change master to指定一遍所有信息
- start slave
2）网络不通、延时高、防火墙没关、反向解析
[root@db02 ~]# ping baidu.com
[root@db02 ~]# systemctl stop firewlld
[root@db02 ~]# show master status; # 查看binlog是否存在
反向解析
#没有跳过反向解析
ERROR 1045 (28000): Access denied for user 'root'@'db01' (using password: YES)
#配置
skip_name_resolve
3）主库重新授权
grant replication slave on *.* to slave@'172.16.1.5%' identified by '123';
mysql> show master status;
PS：密码可能记混，导致IO线程connecting！
- Slave_SQL_Running: No
SQL线程开启失败：
1.主库有的数据，从库没有
2.从库有的数据，主库没有
3.主库与从库数据库结构有差别
#处理方法一：推荐
#临时停止同步
mysql> stop slave;
#将同步指针向下移动一个（可重复操作）解决不了根本问题
mysql> set sql_slave_skip_counter=1;
#开启同步
mysql> start slave;
#处理方法二：推荐，这样从库就只能读，避免误操作
1.要求,主从复制之前,主库和从库的数据保证一致.
2.在从库上设置 只读:set read-only=1; # 不推荐，因为需要重启数据库
（做读写分离时使用，但是做MHA会出现提升为主库时，主库只读，后面会讲专门做读写分离的Atlas）
#处理方法三：
#编辑配置文件
[root@db01 ~]# vim /etc/my.cnf
#在[mysqld]标签下添加以下参数
slave-skip-errors=1032,1062,1007
4.binlog不存在或者损坏，删除，停止并开启主从复制： # 在出问题的从库上操作
[root@db01 ~]# cd /var/lib/mysql
[root@db01 mysql]# ll *.info
-rw-rw---- 1 mysql mysql 49 Mar 5 10:34 master.info
-rw-rw---- 1 mysql mysql 39 Mar 5 10:34 relay-log.info
mysql> stop slave;
mysql> start slave;
开始安装部署MHA：
- 基于以上配置步骤，安装完主从的基础之上，再来进行此操作
MHA的工作流程：
- 把宕机的master二进制日志保存下来。
- 找到binlog位置点最新的slave。
- 在binlog位置点最新的slave上用relay log（差异日志）修复其它slave。
- 将宕机的master上保存下来的二进制日志恢复到含有最新位置点的slave上。
- 将含有最新位置点binlog所在的slave提升为master。
- 将其它slave重新指向新提升的master，并开启主从复制。
MHA架构图：
MHA工具介绍：
MHA软件由两部分组成，Manager工具包和Node工具包，具体的说明如下：
Manager工具包主要包括以下几个工具：
masterha_check_ssh #检查MHA的ssh-key
masterha_check_repl #检查主从复制情况
masterha_manger #启动MHA
masterha_check_status #检测MHA的运行状态
masterha_master_monitor #检测master是否宕机
masterha_master_switch #手动故障转移
masterha_conf_host #手动添加server信息
masterha_secondary_check #建立TCP连接从远程服务器
masterha_stop #停止MHA
Node工具包主要包括以下几个工具：
save_binary_logs #保存宕机的master的binlog
apply_diff_relay_logs #识别relay log的差异
filter_mysqlbinlog #防止回滚事件
purge_relay_logs #清除中继日志
MHA优点总结：
1）Masterfailover and slave promotion can be done very quickly
自动故障转移快
2）Mastercrash does not result in data inconsistency
主库崩溃不存在数据一致性问题
3）Noneed to modify current MySQL settings (MHA works with regular MySQL)
不需要对当前mysql环境做重大修改
4）Noneed to increase lots of servers
不需要添加额外的服务器(仅一台manager就可管理上百个replication)
5）Noperformance penalty
性能优秀，可工作在半同步复制和异步复制，当监控mysql状态时，仅需要每隔N秒向master发送ping包(默认3秒)，所以对性能无影响。你可以理解为MHA的性能和简单的主从复制框架性能一样。
6）Works with any storage engine
只要replication支持的存储引擎，MHA都支持，不会局限于innodb
1.开始配置数据库、做软连接
- MHA高可用部署建议：
- Manager部署到一台新机器或其他slave节点，尽量避免部署在master节点（主库若挂了可以调用其他节点自动升级为主库）
- 我此处是部署在master节点，但尽量还是不要这么做~
1）关闭以下选项（从节点）
mysql> set global read_only=1; # 设置全局只读
mysql> set global relay_log_purge=0; # 关闭全局中继日志清除
PS：推荐不添加到配置文件内，只是临时生效即可
# 因为添加到配置文件内，需要重启数据库；所以，在生产环境内忌讳重启，所以，能修复就好！
2）给mysql和mysqlbinlog命令做软连接，提供给mha使用（所有节点）
[root@Mysql1 ~]# ln -s /usr/bin/mysql /usr/local/bin
[root@Mysql1 ~]# ln -s /usr/bin/mysqlbinlog /usr/local/bin
2.配置免秘钥登录（所有节点）
- 三台服务器都要各自执行以下四步：直接用xshell一键执行所有主机即可
- 给自己和其他主机各发送一份
- 实现三台主机都可以相互免秘钥登录
- 因为mha是通过ssh来检测存在状态的，包括自己也是
[root@localhost ~]# ssh-keygen -t rsa # 一路回车
[root@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.0.51
[root@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.0.52
[root@localhost ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub root@10.0.0.53
3.配置并安装node服务（所有节点）
1）创建目录、解压文件
[root@localhost ~]# mkdir /usr/local/packages
[root@localhost ~]# cd /usr/local/packages/
[root@localhost packages]# rz
[root@localhost packages]# tar -xvf mha4mysql-node-0.56.tar.gz
[root@localhost packages]# cd mha4mysql-node-0.56
[root@localhost mha4mysql-node-0.56]# perl Makefile.PL
PS：此时如果出现报错信息，表示没有安装CPAN模块，安装后重新编译即可
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
Can't locate CPAN.pm in @INC (@INC contains: inc /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at inc/Module/AutoInstall.pm line 277.
2)安装perl-CPAN模块、重新编译
中间若有提示，全都接受
[root@localhost mha4mysql-node-0.56]# yum -y install perl-CPAN
[root@localhost mha4mysql-node-0.56]# perl Makefile.PL
[root@localhost mha4mysql-node-0.56]# make && make install
PS：node安装后也会在/usr/local/bin下面会生成几个脚本，这些工具通常由MHA Manager的脚本触发，无需人为操作，主要如下：
save_binary_logs # 保存和复制 master 的二进制日志
apply_diff_relay_logs # 识别差异的中继日志事件并将其差异的事件应用于其他的 slave
filter_mysqlbinlog # 去除不必要的 ROLLBACK 事件（MHA 已不再使用这个工具）
purge_relay_logs # 清除中继日志（不会阻塞 SQL 线程）
4.db01主节点安装manager管理服务
- 安装mha4mysql-manager管理服务
1）解压、安装
中间若有提示，全都接受，过程大约十分钟
[root@db01 ~]# cd /usr/local/packages
[root@localhost packages]# rz
[root@localhost packages]# tar -xvf mha4mysql-manager-0.56.tar.gz
[root@localhost packages]# cd mha4mysql-manager-0.56
[root@localhost mha4mysql-manager-0.56]# perl Makefile.PL
[root@localhost mha4mysql-manager-0.56]# make && make install
manager安装后在/usr/local/bin下面会生成几个工具，主要包括以下几个：
masterha_check_ssh # 检查 MHA 的 SSH 配置状况
masterha_check_repl # 检查 MySQL 复制状况
masterha_manger # 启动 manager的脚本
masterha_check_status # 检测当前 MHA 运行状态
masterha_master_monitor # 检测 master 是否宕机
masterha_master_switch # 控制故障转移（自动或者手动）
masterha_conf_host # 添加或删除配置的 server 信息
masterha_stop # 关闭manager
3）安装MHA node所需的perl模块（DBD:mysql）
[root@db01 ~]# yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-devel
5.db01主节点管理MHA配置文件
- 在manager主节点上复制相关脚本到/usr/local/bin/
[root@db01 mha4mysql-manager-0.56]# cp -ra samples/scripts/* /usr/local/bin
[root@atlas ~]# ll /usr/local/bin/ # 拷贝后会有四个执行文件，主用前两个
总用量 32
-rwxr-xr-x 1 mysql mysql 3648 5 月 31 2015 master_ip_failover # 自动切换时 VIP 管理的脚本
-rwxr-xr-x 1 mysql mysql 9872 5 月 25 09:07 master_ip_online_change # 在线切换时 vip 的管理
-rwxr-xr-x 1 mysql mysql 11867 5 月 31 2015 power_manager # 故障发生后关闭主机的脚本
-rwxr-xr-x 1 mysql mysql 1360 5 月 31 2015 send_report # 因故障切换后发送报警的脚本
PS：这里使用脚本来管理VIP，也是推荐的一种方式，生产环境不太建议使用 keepalived
6.db01主节点修改IP自动漂移脚本
VIP漂移的两种方式
- 通过keepalived的方式，管理虚拟IP的漂移
- 通过MHA自带脚本方式，管理虚拟IP的漂移
1）漂移的主机为MHA配置文件定义过的主机
- 浏览配置文件结构，后续修改
[root@db01 ~]# cat /etc/masterha/app1.cnf
[server default]
manager_log=/var/log/masterha/app1/manager.log
manager_workdir=/var/log/masterha/app1
master_binlog_dir=/var/lib/mysql
master_ip_failover_script=/usr/local/bin/master_ip_failover
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
ping_interval=1
remote_workdir=/tmp
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 10.0.0.52 -s 10.0.0.53
shutdown_script=""
ssh_user=root
repl_password=rep
repl_user=rep
user=mha
password=mha
[server1]
candidate_master=1
hostname=10.0.0.51
port=3306
[server2]
candidate_master=1
hostname=10.0.0.52
port=3306
[server3]
candidate_master=1
hostname=10.0.0.53
port=3306
2）VIP漂移注意事项
1.首先检查从库的主从状态，若无状态需重新change语句指定！
2./etc/masterha/app1.cnf配置文件出错，不能有带注释的信息！
3.vip漂移后，app1.cnf内的server信息会消失（自动删除），指宕机的主机
- 若修复后需要指回原主机，则需要重新指定主从信息
- 且在app1.cnf内添加会server主机的信息
- 再启动MHA服务即可
3）自动漂移脚本文件
- FIXME_xxx;（注释此行）
[root@node3 mha4mysql-manager-0.56]# vim /usr/local/bin/master_ip_failover
#!/usr/bin/env perl
use strict;
use warnings FATAL => 'all';
use Getopt::Long;
use MHA::DBHelper;
my (
$command, $ssh_user, $orig_master_host,
$orig_master_ip, $orig_master_port, $new_master_host,
$new_master_ip, $new_master_port, $new_master_user,
$new_master_password
);
###################################此处添加此一段即可###################################
#默认是在[server default]标签下添加，若无此标签在此处添加
my $vip = '10.0.0.200/24'; # Virtual IP # 虚拟漂移IP，不与其他节点重复即可（需在10.0.0.0网段内）
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";
###################################此处添加此一段即可###################################
GetOptions(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'new_master_port=i' => \$new_master_port,
'new_master_user=s' => \$new_master_user,
'new_master_password=s' => \$new_master_password,
);
exit &main();
sub main {
if ( $command eq "stop" || $command eq "stopssh" ) {
# $orig_master_host, $orig_master_ip, $orig_master_port are passed.
# If you manage master ip address at global catalog database,
# invalidate orig_master_ip here.
my $exit_code = 1;
eval {
# updating global catalog, etc
$exit_code = 0;
};
if ($@) {
warn "Got Error: $@\n";
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "start" ) {
# all arguments are passed.
# If you manage master ip address at global catalog database,
# activate new_master_ip here.
# You can also grant write access (create user, set read_only=0, etc) here.
my $exit_code = 10;
eval {
my $new_master_handler = new MHA::DBHelper();
# args: hostname, port, user, password, raise_error_or_not
$new_master_handler->connect( $new_master_ip, $new_master_port,
$new_master_user, $new_master_password, 1 );
## Set read_only=0 on the new master
$new_master_handler->disable_log_bin_local();
print "Set read_only=0 on the new master.\n";
$new_master_handler->disable_read_only();
## Creating an app user on the new master
print "Creating app user on the new master..\n";
FIXME_xxx_create_user( $new_master_handler->{dbh} );
$new_master_handler->enable_log_bin_local();
$new_master_handler->disconnect();
## Update master ip on the catalog database, etc
# FIXME_xxx;
$exit_code = 0;
};
if ($@) {
warn $@;
# If you want to continue failover, exit 10.
exit $exit_code;
}
exit $exit_code;
}
elsif ( $command eq "status" ) {
# do nothing
exit 0;
}
else {
&usage();
exit 1;
}
}
sub usage {
print
"Usage: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}
7.MHA主节点创建MHA软件目录，并拷贝配置文件
- MHA主节点用的是db01
[root@db01 ~]# mkdir /etc/masterha
[root@db01 ~]# cp /mha4mysql-manager-0.56/samples/conf/app1.cnf /etc/masterha
[root@db01 ~]# mkdir -p /var/log/masterha/app1/
[root@db01 ~]# ifconfig eth0:1 10.0.0.200/24
8.授权、修改配置文件
1）授权
- 授权创建mha管理用户的用户名
# 所有节点创建并授权用户
mysql> grant replication slave on *.* to rep@'172.16.1.5%' identified by 'rep';
mysql> grant all privileges on *.* to mha@'172.16.1.5%' identified by 'mha';
# 单独在manager节点创建授权用户
mysql> grant all privileges on *.* to mha@'db01' identified by 'mha';
2）修改配置文件
需去除配置文件内的中文注释，才可以启动，否则启动失败！
[root@db01 mha4mysql-manager-0.56]# vim /etc/masterha/app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql # 主库binlog的位置点
master_ip_failover_script=/usr/local/bin/master_ip_failover
master_ip_online_change_script=/usr/local/bin/master_ip_online_change
user=mha
password=mha
repl_user=slave # 主从复制专用用户，在这里指定后，主节点就免授权了
repl_password=slave
ping_interval=1
remote_workdir=/tmp
secondary_check_script= /usr/local/bin/masterha_secondary_check -s 192.168.100.112 -s 192.168.100.105
shutdown_script=""
ssh_user=root
[server1]
hostname=10.0.0.51
candidate_master=1 # 若出现故障，允许成为候选节点
check_repl_delay=0 # 检查复制延迟，可有可无
port=3306
[server2]
hostname=10.0.0.52
port=3306
candidate_master=1
[server3]
hostname=10.0.0.53
candidate_master=1
check_repl_delay=0
port=3306
9.db01主节点状态检查
状态检查，测试无秘钥登录：
[root@db01 mha4mysql-manager-0.56]# masterha_check_ssh -conf=/etc/masterha/app1.cnf
# 输出如下信息表示无秘钥正常
Wed Mar 3 10:57:20 2021 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Mar 3 10:57:20 2021 - [info] Reading application default configuration from /etc/masterha/app1.cnf..
Wed Mar 3 10:57:20 2021 - [info] Reading server configuration from /etc/masterha/app1.cnf..
Wed Mar 3 10:57:20 2021 - [info] Starting SSH connection tests..
Wed Mar 3 10:57:22 2021 - [debug]
Wed Mar 3 10:57:20 2021 - [debug] Connecting via SSH from root@192.168.100.111(192.168.100.111:22) to root@192.168.100.112(192.168.100.112:22)..
Wed Mar 3 10:57:21 2021 - [debug] ok.
Wed Mar 3 10:57:21 2021 - [debug] Connecting via SSH from root@192.168.100.111(192.168.100.111:22) to root@192.168.100.105(192.168.100.105:22)..
Wed Mar 3 10:57:21 2021 - [debug] ok.
Wed Mar 3 10:57:23 2021 - [debug]
Wed Mar 3 10:57:21 2021 - [debug] Connecting via SSH from root@192.168.100.105(192.168.100.105:22) to root@192.168.100.111(192.168.100.111:22)..
Wed Mar 3 10:57:22 2021 - [debug] ok.
Wed Mar 3 10:57:22 2021 - [debug] Connecting via SSH from root@192.168.100.105(192.168.100.105:22) to root@192.168.100.112(192.168.100.112:22)..
Wed Mar 3 10:57:22 2021 - [debug] ok.
Wed Mar 3 10:57:23 2021 - [debug]
Wed Mar 3 10:57:21 2021 - [debug] Connecting via SSH from root@192.168.100.112(192.168.100.112:22) to root@192.168.100.111(192.168.100.111:22)..
Wed Mar 3 10:57:21 2021 - [debug] ok.
Wed Mar 3 10:57:21 2021 - [debug] Connecting via SSH from root@192.168.100.112(192.168.100.112:22) to root@192.168.100.105(192.168.100.105:22)..
Wed Mar 3 10:57:22 2021 - [debug] ok.
Wed Mar 3 10:57:23 2021 - [info] All SSH connection tests passed successfully.
10.db01主节点测试 MySQL 主从连接情况
最后出现 MySQL Replication Health is OK 字样说明正常，如下所示：
[root@db01 mha4mysql-manager-0.56]# masterha_check_repl -conf=/etc/masterha/app1.cnf
Wed Mar 3 11:24:48 2021 - [info] Checking replication health on 192.168.100.112..
Wed Mar 3 11:24:48 2021 - [info] ok.
Wed Mar 3 11:24:48 2021 - [info] Checking replication health on 192.168.100.105..
Wed Mar 3 11:24:48 2021 - [info] ok.
Wed Mar 3 11:24:48 2021 - [info] Checking master_ip_failover_script status:
Wed Mar 3 11:24:48 2021 - [info] /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.100.111 --orig_master_ip=192.168.100.111 --orig_master_port=3306
Wed Mar 3 11:24:48 2021 - [info] OK.
Wed Mar 3 11:24:48 2021 - [warning] shutdown_script is not defined.
Wed Mar 3 11:24:48 2021 - [info] Got exit code 0 (Not master dead).
MySQL Replication Health is OK.
报错案例1：出现权限报错信息
- 对应授权即可，一般为mha授权
报错案例2：调用mysqlbinlog失败
- 检查软连接是否飘红 /usr/local/bin/mysql
- 检查软连接是否飘红 /usr/local/bin/mysqlbinlog
- 飘红为不可用，删除后重新做软连接即可
11.启动MHA
1）启动命令
[root@node1 mha4mysql-manager-0.56]# nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
2）参数说明
–manger_log # 日志存放位置
–remove_dead_master_conf # 该参数代表当发生主从切换后，老的主库的 ip 将会从配置文件中移除。
–ignore_last_failover # 忽略上次 MHA 触发切换产生的文件
PS：在缺省情况下，如果 MHA 检测到连续发生宕机，且两次宕机间隔不足 8 小时的话，则不会进行 Failover；
之所以这样限制是为了避免 ping-pong 效应，该参数代表忽略上次 MHA 触发切换产生的文件；
默认情况下，MHA 发生切换后会在日志记目录，也就是上面设置的日志 app1.failover.complete 文件；
下次再次切换的时候如果发现该目录下存在该文件将不允许触发切换，除非在第一次切换后收到删除该文件。
为了方便，这里设置为 –ignore_last_failover
12.查看 MHA 状态
可以看到当前的master是node1主节点：
[root@db01 mha4mysql-manager-0.56]# masterha_check_status --conf=/etc/masterha/app1.cnf
app1 (pid:6124) is running(0:PING_OK), master:10.0.0.51
13.查看 MHA 日志
也以看到当前的 master 是 10.0.0.51，如下所示：
[root@db01 mha4mysql-manager-0.56]# cat /var/log/masterha/app1/manager.log
Wed Mar 3 11:25:50 2021 - [info] Checking master_ip_failover_script status:
Wed Mar 3 11:25:50 2021 - [info] /usr/local/bin/master_ip_failover --command=status --ssh_user=root --orig_master_host=10.0.0.51 --orig_master_ip=10.0.0.51 --orig_master_port=3306
PS：至此，已经完成高可用配置！
14.如何关闭MHA manage监控？
[root@db01 mha4mysql-manager-0.56]# masterha_stop --conf=/etc/masterha/app1.cnf
扫一扫
403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
