MHA高可用部署

MHA

MHA（Master High Availability）是一套相对成熟的MySQL高可用方案，能做到在0~30s内自动完成数据库的故障切换操作，在master服务器不宕机的情况下，基本能保证数据的一致性。

通过提升某一节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA要求一个复制集群中必须最少有三台数据库服务器，一主二从

它由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。其中，MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。MHA Node则运行在每个mysql节点上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它自动将最新数据的slave提升为master，然后将其它所有的slave指向新的master。

在MHA自动故障切换过程中，MHA试图保存master的二进制日志，从而最大程度地保证数据不丢失，当这并不总是可行的，譬如，主服务器硬件故障或无法通过ssh访问，MHA就没法保存二进制日志，这样就只进行了故障转移但丢失了最新数据。可结合MySQL 5.5中推出的半同步复制来降低数据丢失的风险。

---

MHA软件由两部分组成：Manager工具包和Node工具包，具体说明如下：

MHA Manager：

masterha_check_ssh：检查MHA的SSH配置状况

masterha_check_repl：检查MySQL的复制状况

masterha_manager：启动MHA

masterha_check_status：检测当前MHA运行状态

masterha_master_monitor：检测master是否宕机

masterha_master_switch：控制故障转移（自动或手动）

masterha_conf_host：添加或删除配置的server信息

masterha_stop：关闭MHA

MHA Node:

save_binary_logs：保存或复制master的二进制日志

apply_diff_relay_logs：识别差异的relay log并将差异的event应用到其它slave中

filter_mysqlbinlog：去除不必要的ROLLBACK事件（MHA已不再使用这个工具）

purge_relay_logs：消除中继日志（不会堵塞SQL线程）

环境
四台centos7，数据库使用的centos7镜像中默认的mariadb5.5
四台角色分别为

主数据库			192.168.40.7 		写入

备用数据库		192.168.40.17		读

从数据库         192.168.40.27		读

MHA监控主机		192.168.244.40 		监控

其中，master对外提供写服务，备选master提供读服务，slave也提供相关的读服务，一旦master宕机，将会把备选master提升为新的master，slave指向新的master

安装相关依赖包

yum install perl-DBD-MySQL perl-ExtUtils-MakeMaker  perl-CPAN -y

在大牛的网盘中下载MHA包，请点击

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

在网盘里下载了上传到虚拟机，lrzsz包

1、在所有节点上安装node

yum install -y mha4mysql-node-0.56-0.el6.noarch.rpm

2、然后在manager监控节点安装manager

yum install -y mha4mysql-manager-0.56-0.el6.noarch.rpm

3、manager监控节点SSH的key验证，全部互通

ssh-keygen
ssh-copy-id 192.168.40.5
scp -r .ssh 192.168.40.7:/root/
scp -r .ssh 192.168.40.17:/root/
scp -r .ssh 192.168.40.27:/root/

搭建数据库主从架构

涉及选项：
  log-bin：开启日志记录
  binlog-format：二进制日志记录格式
  server-id：为当前节点设置一个全局唯一的ID号
  read-only：设置数据库只读，从服务器添加，让从服务器不能被用户有写操作，所有的更新来源来自主服务器
  skip_name_resolve ：禁止IP转换为域名
  relay_log_purge=0 ：是否清楚中继，0为不清除，中继日志中记录着部分复制过来的内容，所以不能清除，清除了没法恢复

步骤：
1）安装好数据库启动先不启动，先修改配置文件

yum install -y mariadb-server

其中包含很多文件，我也不介绍了，想看使用 rpm -ql mariadb-server 查看

2）主服务器配置40.7： 添加项，启动服务

vim /etc/mysql.cnf
[mysqld]
server-id=1
log-bin
binlog-format=row
skip_name_resolve

3）既然提到复制，那么就肯定设计到交互，需要创建一个专用于复制的用户来同步数据。

在数据库中执行

grant replication slave on *.* to 'replslave'@'192.168.40.%' identified by '123123'; 

使用：select user,host,password from mysql.user; 查看创建的用户

4、从服务器配置40.17： 添加项，启动服务

vim /etc/my.cnf
[mysqld]
server-id=2
log-bin
binlog-format=row
skip_name_resolve
relay_log_purge=0
read-only			# 从服务器的read-only需要加，替换为主服务器的时候，会自动将此项关闭

# 因为这台将来要充当为主服务器，所以要开启日进制日志

5、从服务器配置40.27： 添加项，启动服务

vim /etc/my.cnf
[mysqld]
server-id=3
read-only
skip_name_resolve

6、主从复制，需要告诉从服务器从哪里开始复制主服务器的数据，关键指令change master to

在两台从数据库40.17和40.27中执行

help change master to; 查看命令帮助，记不住没关系

执行：

CHANGE MASTER TO
	MASTER_HOST='192.168.40.7',
	MASTER_USER='replslave',		
	MASTER_PASSWORD='123123',		
    MASTER_PORT=3306,					
	MASTER_LOG_FILE='mariadb-bin.000001',
	MASTER_LOG_POS=245;

解释：
CHANGE MASTER TO
	MASTER_HOST='192.168.40.7',			：主服务器地址
	MASTER_USER='replslave',			：有复制权限的用户
	MASTER_PASSWORD='123123',			：用户密码
    MASTER_PORT=3306,					：主服务器端口
	MASTER_LOG_FILE='mariadb-bin.000001',	
		# 主服务器的二进制日志，此处添的应该是你要从哪个二进制开始同步的那个文件
		# 我们这里是刚安装的环境所以是从1开始，指定位置时，开始默认是245，我们也需要将刚才创建的窗户复制过来
	MASTER_LOG_POS=245;					：从二进制文件的哪个位置开始

接着执行：
	start slave;	# 启动复制
	show slave status\G		# 查看复制状态
	挑部分内容介绍：
		   	  Master_Host: 192.168.40.7			主服务器IP
              Master_User: replslave			有权限复制的用户
              Master_Port: 3306					端口
            Connect_Retry: 60		
          Master_Log_File: mariadb-bin.000001	主服务器的日进制日志文件
      Read_Master_Log_Pos: 403					主服务器的二进制日志文件当前位置
           Relay_Log_File: mariadb-relay-bin.000002		本机，从服务器记录的中继日志文件
            Relay_Log_Pos: 689							中继日志的记录位置
    Relay_Master_Log_File: mariadb-bin.000001
         Slave_IO_Running: Yes				IO线程状态，复制正常YES
        Slave_SQL_Running: Yes				SQL线程状态，回滚重写正常

7、在主服务器上创建监控用户

grant all privileges on *.* to 'monitor'@'192.168.40.%' identified by 'monitor123';

---

配置MHA

在MHA监控设备上[192.168.40.5]创建工作目录，创建配置文件

[root@centos7_5 ~]# mkdir /etc/mha
[root@centos7_5 ~]# vim /etc/mha/app1.conf

[server default]
user=mhauser
password=123123
manager_workdir=/data/mastermha/app1/
manager_log=/data/mastermha/app1/manager.log
remote_workdir=/data/mastermha/app1/
ssh_user=root
repl_user=replslave
repl_password=123123
ping_interval=1         

[server1]
hostname=192.168.40.7
candidate_master=1
[server2]
hostname=192.168.40.17
candidate_master=1
[server3]
hostname=192.168.40.27
candidate_master=1

mha验证和启动
产生的内容太多，我就不贴了

检查SSH的状态

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

检查整个集群的状态

masterha_check_repl --conf=/etc/mha/app1.conf

启动MHA监控
masterha_manager --conf=/etc/mha/app1.conf

Fri Nov 15 18:27:10 2019 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Fri Nov 15 18:27:10 2019 - [info] Reading application default configuration from /etc/mha/app1..
Fri Nov 15 18:27:10 2019 - [info] Reading server configuration from /etc/mha/app1..
# 会一直停留在这个状态，监控主服务器的状态

检查期间可能会报错误，可参考总结错误提示

测试
将40.7主服务关闭，测试40.17备机能否成功上位成为主服务器

停止后监控将执行换主动作，然后终止，MHA的工作结束，他就是为了等这一刻

在创建40.17的时候当时设置的read-only一项在切换主成功后，也会被注释

cat /etc/my.cnf
[mysqld]
server-id=2
log-bin
binlog-format=row
skip_name_resolve
relay_log_purge=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
#read-only

而40.27这台普通的从服务器复制的change master to的主也指向新的40.17

  MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.40.17
                  Master_User: replslave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000001
          Read_Master_Log_Pos: 245
               Relay_Log_File: mariadb-relay-bin.000002
                Relay_Log_Pos: 531
        Relay_Master_Log_File: mariadb-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes