Rocky9MySQL读写分离，mysql高可用

实验目的

掌握mysql主从复制，主节点VIP漂移变成备节点并加入到已经进行的mysql主机中，如何配置并启动slave节点，通过备份恢复数据至从服务器，复制起始位置为备份时，还有加入当前postion节点实现中途加入主从复制，掌握mysql的读写分离和mha高可用。

实验主要内容

1、mha实现mysql高可用

2、主节点mysqlVIP漂移且变成备节点

3、原主节点恢复成主节点

实验环境与准备

5台拍完快照配置好的linux主机，1台为manager管理主机且安装安装node和manager，主从节点都安装node，mysql，一台mycat服务器

四、实验分析与设计思路

建议基于画图、思维导图等模式，结合文字描述，写的清晰、明了、得体

MHA工作原理

1 MHA利用SELECT 1 As Value指令判断master服务器的健康性，一旦master宕机，MHA从宕机崩溃的master保存二进制日志事件（binlog events）

2 识别含有最新更新的slave

3 应用差异的中继日志（relay log）到其他的slave

4 应用从master保存的二进制日志事件（binlog events）

5 提升一个slave为新的master

6 使其他的slave连接新的master进行复制

MHA软件由两部分组成，Manager工具包和Node工具包

Manager工具包主要包括以下几个工具：

masterha_check_ssh 检查MHA的SSH配置状况

masterha_check_repl 检查MySQL复制状况

masterha_manger 启动MHA

masterha_check_status 检测当前MHA运行状态

masterha_master_monitor 检测master是否宕机

masterha_master_switch 故障转移（自动或手动）

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

Node工具包：这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

save_binary_logs 保存和复制master的二进制日志

apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave

filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用此工具）

purge_relay_logs 清除中继日志（不会阻塞SQL线程）

五、详细实验过程

1、mysql主机实现高可用 注意（mha主机需要使用centOS7主机）

首先要保证四台主机保持免密登录，这里我的mha主机为10.140，mycat主机为10.130，初始主节点为100，两个备节点为110和120，昨天的实验中已经安装了mysql并且已经成为了主从复制的状态，但是再次登录的时候已经没有了主从复制效果，需要重新配置

步骤：①：实现基于KEY密码认证

vim /etc/mastermha/app1.cnf

免密登录脚本 需要将脚本和sshpass-1.08.tar.gz都复制到root路径下

vim mianmi.sh

bash mianmi.sh

manager管理节点上添加邮件发送设置，先安装邮件客户端

yum -y install mailx

vim /etc/mail.rc

编写邮件客户端自动发送邮件脚本

vim /usr/local/bin/sendmail.sh

#!/bin/bash

echo "MySQL is down" | mail -s "MHA Warning" 599958344@qq.com

②：manager节点两个mha程序包都需要安装（先安装node，在安装manager，需要使用epel源），其他被管理节点只需安装node包

centOS7上的manager安装：

yum -y localinstall mha4mysql-node-0.58-0.el7.centos.noarch.rpm

yum -y localinstall mha4mysql-manager-0.58-0.el7.centos.noarch.rpm

主备节点安装

yum -y localinstall mha4mysql-node-0.58-0.el7.centos.noarch.rpm

导入VIP漂移脚本，加上执行权

chmod +x /usr/local/bin/master_ip_failover

master主节点数据库主配置文件配置

为主节点的mysql数据库配置文件打开通用日志格式 general_log

下面为备节点的设置，备节点除了ip其他都无异

登录master主节点，RESET二进制日志，并查看pos位置

mysql -u root -p

RESET MASTER LOGS;

授权从节点复制账号

create user repluser@'%' identified by '123456';

alter user 'repluser'@'%' identified with mysql_native_password by '123456';

grant replication slave on *.* to repluser@'%';

flush privileges;

重新进行主从节点的连接----复制 RESET SLAVE ALL 清除所有从服务器上设置的主服务器同步信息如：PORT, HOST, USER和 PASSWORD 等

show slave status\G;

将主从节点的内容保持一致，数据库和数据表的内容必须一致

然后将从节点指向主节点进行连接

两边都进行开启 start slave; show slave status\G; 可以见到已经变成了yes

mysql> change master to

-> master_host='192.168.10.100',

-> master_user='repluser',

-> master_password='123456',

-> master_port=3306,

-> master_log_file='binlog.000001',

-> master_log_pos=157;

在主节点添加数据，验证是否主从复制成功

查看从节点也添加上了数据，验证成功

在主节点创建授权mha管理数据库的账号

create user mhauser@'%' identified by '123456';

alter user 'mhauser'@'%' identified with mysql_native_password by '123456';

grant all on *.* to mhauser@'%';

flush privileges;

确保MHA和repluser账号表在从节点已经同步

可以看到在主节点和备节点都同步上了mha管理账号和repluser账号

select user,host,authentication_string from mysql.user;

vim master_ip_failover 网关需要更改一下

在manager管理节点上运行MHA语法和配置检测程序，检测运行环境是否正常

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

masterha_check_repl --conf=/etc/mastermha/app1.cnf

运行一切正常！

Mycat服务器配置环境变量PATH=$PATH:/usr/local/mycat/bin/ 临时生效

启动mycat mycat start

可以看到mycat服务器的代理作用已经启动

use TESTDB show tables; select * from baby;

在主节点设置VIP

ifconfig eth0:1 192.168.10.88/24

查看主节点和从节点的通用日志（主节点一直被MHA监测，从节点没有）

tail -f /var/lib/mysql/node-1.log 主节点通用日志

tail -f /var/lib/mysql/node-2.log 备节点110通用日志

tail -f /var/lib/mysql/node-3.log 备节点120通用日志

查看主节点的读写状态（主为0为写，从为1为读）

select @@read_only;

在mycat上查看轮询效果select @@server_id;

将主节点进行停服，验证MHA是否将某个从节点升级为主节点

前台mha主机启动MHA进程，并实时监控

masterha_manager --conf=/etc/mastermha/app1.cnf

主节点：systemctl stop mysqld VIP已漂移 查看邮件发送情况

从节点110上我们可以看到VIP飘过来了

2.将现在的100节点加入到主从复制中成为备节点

我们进行将原来的100主节点变成从节点小弟，一定要保证他们是处于数据库内容一致的状态

重新进行主从节点的连接----复制 RESET SLAVE ALL 清除所有从服务器上设置的主服务器同步信息如：PORT, HOST, USER和 PASSWORD 等

show slave status\G;

将主从节点的内容保持一致，数据库和数据表的内容必须一致

然后将从节点指向主节点进行连接

这一步做错了，我应该直接用100从节点加入到现有的pos上，然后我删除完slave才发现，然后就只能又加入一遍，做了一次主从复制操作

mysql> change master to

-> master_host='192.168.10.110',

-> master_user='repluser',

-> master_password='123456',

-> master_port=3306,

-> master_log_file='binlog.000001',

-> master_log_pos=157;

两边都进行开启 start slave; show slave status\G; 可以见到已经变成了yes

show processlist; 可以看到在主节点上已经有了两个从节点

主节点插入数据

insert into baby set id=8,name='fyf';

select * from baby;

从节点也是同步的select * from baby;

100加入到主从复制成功

3.将主节点的VIP返回给100

cd /data/mastermha/app1 必须将manager的app1.failover.complete这个文件删除不然VIP票不回去 rm -rf app1.failover.complete 110上的VIP就飘走了

可以看到VIP已经飘到100主机上了

查看100主节点上的pos，现在是1020 show master status;

因为刚才的110节点刚刚经历了一次主节点到自由无业人士的过程，所以110需要加入到主节点

mysql> change master to

-> master_host='192.168.10.100',

-> master_user='repluser',

-> master_password='123456',

-> master_port=3306,

-> master_log_file='binlog.000001',

-> master_log_pos=1020;

插入一条数据验证是否主从复制配置完成，一切正常！

实验结果及分析

在操作中出现了挺多失误的，比如主节点VIP漂移之后，变成从节点的配置时需要加入到原来的posttion节点，但是我操作的时候忘记了，把日志记录全删了，然后就又重新连接到主节点去做的，后来原主节点恢复成主节点的时候我想起来了，就是用加入当前节点的方式做的，还有app1.cnf那块配置没修改日志路径，需要注意的点还是挺多的。