MySQL高可用架构MHA

港南四大炮亡

于 2023-03-28 00:51:35 发布

阅读量279

点赞数

文章标签： mysql 架构数据库

本文链接：https://blog.csdn.net/lpx1249115962/article/details/129807495

版权

0.MHA高可用架构原理
MHA是数据库高可用的一种很好的方案

一主2从
M S1 S2
皇帝皇子1 皇子2

皇帝死了,谁继承皇位?

(1)选主
   提前选定主:太子
   1.数据最全:
   1)只做从库,不提供读写服务,干等接管,百度.
   2)半同步从库.实时复制.

   2.皇帝没有选,死了以后
   皇子互相残杀,竞争皇位

(2)数据补全
1.SSH连接主库,看是否能连接.
如果能连接,去取BINLOG加上中继日志,补全到作为太子的从库.
   如果连不上,以作为太子的库为最新的库(如果没有提前确定主,则会比对看谁的binlog多,则为主).
2.让其他的从,和新主数据保持一致.

(3)角色切换
   作为太子的从库,成为皇帝.
   1)reset slave all; reset master
   2)开启binlog
   3)取消read_only类似只读参数
   4)创建复制用户
(4)让其它的从库和新主做主从.
change master to....

(5) VIP漂移到新主

1. MHA高可用架构介绍及搭建实践

1.1 规划:
主库:
51 mha node

从库:
52 mha node
53 mha node mha manager（可以安装别的机器）

1.2 准备环境
1主2从GTID复制环境,参考GTID复制
老男孩79期讲课是按照传统复制讲解的MHA

已确认1主2从GTID复制环境,

1.3 配置关键程序软连接（所有节点）
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql

1.4 配置各节点互信(各节点之间无密码SSH)
分别在db01/db02/db03上执行如下命令创建秘钥对并执行拷贝秘钥命令。
#db01/db02/db03：
ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa >/dev/null 2>&1
ssh-copy-id -i ~/.ssh/id_dsa.pub 172.16.1.51
ssh-copy-id -i ~/.ssh/id_dsa.pub 172.16.1.52
ssh-copy-id -i ~/.ssh/id_dsa.pub 172.16.1.53

##从任意一个节点都能不输入密码访问MHA其它节点。

为什么?
因为MHA在主或从,两两之间都会比对数据

各节点验证
#db01:
ssh 172.16.1.51 date
ssh 172.16.1.52 date
ssh 172.16.1.53 date
#db02:
ssh 172.16.1.51 date
ssh 172.16.1.52 date
ssh 172.16.1.53 date
#db03:
ssh 172.16.1.51 date
ssh 172.16.1.52 date
ssh 172.16.1.53 date
缺点?
一台机器被攻破,所有机器沦陷.

0.5 安装软件
0.5.1 下载mha软件
mha官网：https://code.google.com/archive/p/mysql-master-ha/
github下载地址：https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

0.5.2 所有节点安装Node软件依赖包
yum install mha4mysql-node-0.58-0.el7.centos.noarch.rpm -y

0.5.3 Manager软件安装（db03）
管理安装节点所需依赖
yum install -y perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
yum install mha4mysql-manager-0.58-0.el7.centos.noarch.rpm -y

0.5.4 在db01主库中创建mha需要的用户
create user mha@'172.16.1.%' identified with mysql_native_password by 'mha';
grant all privileges on *.* to mha@'172.16.1.%' ;
注意:所有从库自动创建好了

db03:::db03:::db03:::db03:::db03:::db03:::db03:::
0.6 配置管理节点文件准备(db03)

0.6.1 创建配置文件目录
mkdir -p /etc/mha

0.6.2 创建日志目录
mkdir -p /var/log/mha/app1

0.6.3 编辑mha配置文件
cat >/etc/mha/app1.cnf<<'EOF'
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/3306/binlog
user=mha
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root

[server1]
hostname=172.16.1.51
port=3306
[server2]
hostname=172.16.1.52
candidate_master=1
port=3306
[server3]
hostname=172.16.1.53
port=3306
EOF

0.7 状态检查
### SSH互信检查
masterha_check_ssh --conf=/etc/mha/app1.cnf
#All SSH connection tests passed successfully.

### 主从状态检查
masterha_check_repl --conf=/etc/mha/app1.cnf
#MySQL Replication Health is OK.

db03 mha manager安装故障解决:
yum install *GD* -y
yum install *DBD* -y

0.8 开启MHA(db03)：
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 &

0.9 查看MHA状态
masterha_check_status --conf=/etc/mha/app1.cnf
#app1 (pid:3152) is running(0:PING_OK), master:172.16.1.51
db03:::db03:::db03:::db03:::db03:::

2. MHA的软件结构
一堆perl写的脚本。
[root@db03 ~]# rpm -ql mha4mysql-manager
/usr/bin/masterha_check_repl
/usr/bin/masterha_check_ssh
/usr/bin/masterha_check_status
/usr/bin/masterha_conf_host
/usr/bin/masterha_manager
/usr/bin/masterha_master_monitor
/usr/bin/masterha_master_switch
/usr/bin/masterha_secondary_check
/usr/bin/masterha_stop

2.1 manager 组件
masterha_manger 启动MHA
masterha_check_ssh     检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
==========================================
masterha_master_switch     控制故障转移（自动或者手动）
masterha_conf_host     添加或删除配置的server信息

2.2 node组件
[root@db03 ~]# rpm -ql mha4mysql-node
/usr/bin/apply_diff_relay_logs
/usr/bin/filter_mysqlbinlog
/usr/bin/purge_relay_logs
/usr/bin/save_binary_logs

save_binary_logs   保存拷贝宕机的主库的binlog日志数据
apply_diff_relay_logs   对比relay log（中继日志）的差异，并补全到各从节点
filter_MySQLbinlog   过滤掉无用的回滚事件
purge_relay_logs   清除无用的relay log（中继日志）

3. 站在产品经理角度，评估高可用软件设计
3.1 监控

3.2 选主

3.3 数据补偿

3.4 故障转移(角色切换,从库和新主库同步)

3.5 应用透明(业务无感知,VIP自动漂移)

4. MHA FailOver 原理
看图说话。
MHA工作原理：

5. 模拟故障并恢复
5.0 工作状态查看
[root@db03 app1]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:17501) is running(0:PING_OK), master:172.16.1.51

5.1 宕主库测试
>/var/log/mha/app1/manager
[root@db01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL............ SUCCESS!

5.2 看日志
[root@db03 app1]#tail -f /var/log/mha/app1/manager
###Master failover to 172.16.1.52(172.16.1.52:3306) completed successfully.

注意:发生主库宕机切换立马配置VIP到db02
ifconfig eth0:52 172.16.1.55/24 up

5.3 恢复
5.3.1 修复故障节点
[root@db01 ~]# /etc/init.d/mysqld start
Starting MySQL.. SUCCESS!
问题：故障节点启动后，会自动接管会主库么？
解答：不会，因为mha管理节点已经退出了。
如果还想使用MHA，需要管理员重新配置，并启动管理服务。

5.3.2 恢复主从
change master to
master_host='172.16.1.52',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1; ##如果是传统复制注意改为普通设置
start slave;

5.3.3 修复配置文件

方法一：
vim /etc/mha/app1.cnf
[server1]
candidate_master=1
hostname=172.16.1.51
port=3306

方法二：
masterha_conf_host --command=add --conf=/etc/mha/app1.cnf --hostname=172.16.1.51 --block=server10 --params="port=3306"

masterha_conf_host --command=delete --conf=/etc/mha/app1.cnf --block=server1

5.3.4 预检测脚本
masterha_check_ssh --conf=/etc/mha/app1.cnf
masterha_check_repl --conf=/etc/mha/app1.cnf

5.3.5 启动MHA
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 &

masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:24316) is running(0:PING_OK), master:172.16.1.52

生产不要切换，直接用52当主就好，切换有风险。

如果在测试:
>/var/log/mha/app1/manager

6. 应用透明---VIP
方法1:首先设置一个VIP,对外提供服务。wvip: 172.16.1.55/24,当数据库宕机后，MHA实现高可用切换的
同时会触发脚本，实现VIP漂移。

方法2:用keepalived替代,可以设置mysql宕机,即关闭数据库,从而让VIP漂移

6.1 vip 故障转移脚本
cd /usr/local/bin

上传脚本文件到/usr/local/bin下
unzip mha_script.zip
mv mha_script/* .

6.2 修改权限
chmod +x /usr/local/bin/*

6.3 修改内容
[root@db03 bin]# vim master_ip_failover +13
13 my $vip = '172.16.1.55/24'; #设置VIP
14 my $key = '1';
15 my $ssh_start_vip = "/sbin/ifconfig eth1:$key $vip"; #启动VIP
16 my $ssh_stop_vip = "/sbin/ifconfig eth1:$key down"; #停止VIP
17 my $ssh_Bcast_arp= "/sbin/arping -I eth1 -c 3 -A 172.16.1.55"; #让切换后的arp表更新。

6.4 修改Manager 配置文件
vim /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover

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

[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf

6.6 手工在主库添加VIP

[root@db02 ~]# ifconfig eth1:1 172.16.1.55/24

6.7 MHA切换效果测试

1.创建远程连接管理员
mysql> create user oldboy@'172.16.1.%' identified with mysql_native_password by 'oldboy123';
mysql> grant all on *.* to oldboy@'172.16.1.%' with grant option;
mysql> flush privileges;

2.然后使用mysql客户端连接（）
[root@db03 bin]# mysql -uoldboy -poldboy123 -h172.16.1.55 -P3306
测试MHA vip功能

7.4 模拟主库宕机
7.4.1 确认主库
[root@db03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:27096) is running(0:PING_OK), master:172.16.1.52

7.4.2 宕主库db01系统
[root@db01 ~]# init 0

7.4.3 观察vip漂移,看日志,主从接管情况

7.5 修复MHA架构为1主2从
略
结论:MHA可以实现VIP漂移,这里也可以使用keepalved实现VIP漂移,
MHA只用做,选主,数据补偿,角色切换，以及切换后从库和主库复制工作

7.6 高可用标准及数据库高可用架构选择
企业高可用标准：全年无故障时间
无故障时间故障时间
99.9% 0.1% = 525.6 min KA+双主：人为干预
99.99% 0.01% = 52.56 min MHA ：半自动化
99.999% 0.001% = 5.256 min PXC、MGR、MGC
99.9999% 0.0001% = 0.5256 min 自动化、云化RDS、平台化

MHA适合物理服务器的数据库高可用，云化RDS,不用MHA了。