第二十一周-day90-数据库day12-MHA高可用架构

1. 查看MHA配置文件

[root@db03 ~]# cat /etc/mha/app1.cnf
[server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/data/binlog       
user=mha                                   
password=mha                               
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root                               
[server1]                                   
hostname=10.0.0.51
port=3306                                  
[server2]            
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306

2. 检查主从状态

[root@db03 ~]# masterha_check_repl --conf=/etc/mha/app1.cnf

MySQL Replication Health is OK.

3.开启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 &

1. 主从复制架构演变介绍

1.1 基本结构

(1)一主一从
(2)一主多从
(3)多级主从
(4)双主
(5)循环复制

1.2 高级应用架构演变

1.2.1 高性能架构
(1) 读写分离架构(读性能较高)
代码级别
MySQL proxy (Atlas,mysql router,proxySQL(percona),maxscale)、
amoeba(taobao)
xx-dbproxy等。

(2) 分布式架构(读写性能都提高):
分库分表——cobar--->TDDL(头都大了),DRDS
Mycat--->DBLE自主研发等。
NewSQL-->TiDB
1.2.2 高可用架构
(3)单活:MMM架构——mysql-mmm(google)
(4)单活:MHA架构——mysql-master-ha(日本DeNa),T-MHA
(5)多活:MGR ——5.7 新特性 MySQL Group replication(5.7.17) --->Innodb Cluster  
(6)多活:MariaDB Galera Cluster架构,(PXC)Percona XtraDB Cluster、MySQL Cluster(Oracle rac)架构

2. 高可用MHA ☆☆☆☆☆

2.1 架构工作原理

1. MHA通过脚本(masterha_master_monitor)实时监控主库的状态(主机,数据库状态)
2. 监控到主库宕机之后,会发生自动选主(masterha_master_switch )
	(1) 权重: 参数
	(2) 日志量
	(3) 配置文件的顺序
3. 数据补偿
	(1) 当主库SSH能够连接,各个从库会立即保存(save_binary_logs)缺失部分的日志到/var/tmp,进行数据补偿.
	(2) 当主库SSH无法连接,通过脚本(apply_diff_relay_logs)自动进行从库的relaylog的差异处理,进行数据补偿.
4. 构建新的主从关系,并将故障节点移除(配置文件移除)	
5. MHA主进程完成工作后,自动退出.

6. 应用透明 VIP(master_ip_failover_script=/usr/local/bin/master_ip_failover)
7. 故障通知	(report_script=/usr/local/bin/send)
8. 提供额外数据补偿的手段(binlog server)
9. 自动自愈,待开发....

2.2 架构介绍:

1主2从,master:db01   slave:db02   db03 ):
MHA 高可用方案软件构成
Manager软件:选择一个从节点安装
Node软件:所有节点都要安装

2.3 MHA软件构成

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信息

Node工具包主要包括以下几个工具:

这些工具通常由MHA Manager的脚本触发,无需人为操作
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志(不会阻塞SQL线程)

2.4 MHA环境搭建

上篇文章末尾已搭建完成 ctrl+f搜索MHA搭建


2.5 故障模拟测试

2.5.1 关闭51主库(db01上)
[root@db01 ~]# /etc/init.d/mysqld stop
Shutting down MySQL............ SUCCESS! 
2.5.2 此时主库跳到52上(db03上查看)


2.5.3 修复主库
[root@db01 ~]# /etc/init.d/mysqld start
Starting MySQL. SUCCESS! 
2.5.4 修复从库
[root@db01 ~]# mysql -e "change master to master_host='10.0.0.52',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;"
[root@db01 ~]# mysql -e  "start slave;"

[root@db01 ~]# mysql -e  "show slave status \G"|grep Running:
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
2.5.5 修改配置文件(db03)

2.5.6 启动MHA (db03)
[root@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 &
[1] 7658
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:7658) is running(0:PING_OK), master:10.0.0.52

2.6 Manager额外参数介绍

说明:
主库宕机谁来接管?
1. 所有从节点日志都是一致的,默认会以配置文件的顺序去选择一个新主。
2. 从节点日志不一致,自动选择最接近于主库的从库
3. 如果对于某节点设定了权重(candidate_master=1),权重节点会优先选择。
但是此节点日志量落后主库100M日志的话,也不会被选择。可以配合check_repl_delay=0,关闭日志量的检查,强制选择候选节点。
(1)  ping_interval=1
#设置监控主库,发送ping包的时间间隔,尝试三次没有回应的时候自动进行failover

(2) candidate_master=1
#设置为候选master,如果设置该参数以后,发生主从切换以后将会将此从库提升为主库,即使这个主库不是集群中事件最新的slave

(3)check_repl_delay=0
#默认情况下如果一个slave落后master 100M的relay logs的话,
MHA将不会选择该slave作为一个新的master,因为对于这个slave的恢复需要花费很长时间,
通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时,
这个参数对于设置了candidate_master=1的主机非常有用,因为这个候选主在切换的过程中一定是新的master

2.7 MHA的vip功能(db03)

2.7.1 拷贝master_ip_failover脚本到/user/local/bin下
[root@db03 /server/tools]# ll
total 9936
-rw-r--r-- 1 root root 4963681 Jun 28 11:35 Atlas-2.2.1.el6.x86_64.rpm
-rw-r--r-- 1 root root   20904 Jun 28 11:36 email_2019-最新.zip
-rw-r--r-- 1 root root    2248 Jun 28 11:36 master_ip_failover.txt
-rw-r--r-- 1 root root 5051108 Aug 19 18:16 MHA-2019-6.28.zip
-rw-r--r-- 1 root root   87119 Jun 28 11:34 mha4mysql-manager-0.56-0.el6.noarch.rpm
-rw-r--r-- 1 root root   36326 Jun 28 11:35 mha4mysql-node-0.56-0.el6.noarch.rpm

[root@db03 /server/tools]# cp master_ip_failover.txt /usr/local/bin/master_ip_failover

[root@db03 /server/tools]#  cd /usr/local/bin/
[root@db03 /usr/local/bin]# yum install -y dos2unix

[root@db03 /usr/local/bin]# dos2unix master_ip_failover 
dos2unix: converting file master_ip_failover to Unix format ...

[root@db03 /usr/local/bin]# chmod +x master_ip_failover 

####2.7.2 更改manager配置文件:

vim /etc/mha/app1.cnf
添加此行:
master_ip_failover_script=/usr/local/bin/master_ip_failover
2.7.3 修改文件内容:
[root@db03 /usr/local/bin]# vim /usr/local/bin/master_ip_failover 
my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

 vim /usr/local/bin/master_ip_failover

2.7.4 主库上,手工生成第一个vip地址(db02)

手工在主库上绑定vip,注意一定要和配置文件中的ethN一致,我的是eth0:1(1是key指定的值)

ifconfig eth0:1 10.0.0.55/24
2.7.8 重启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 &

2.7.9 邮件提醒

(1) 添加配置选项
vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send
(2) 拷贝脚本
[root@db03 /server/tools]# cp email/*  /usr/local/bin
(3) 添加执行权限
[root@db03 /usr/local/bin]# chmod +x ./*
[root@db03 /usr/local/bin]# ll
total 92
-rwxr-xr-x 1 root root  2166 Aug 20 15:44 master_ip_failover
-rwxr-xr-x 1 root root    35 Aug 20 15:52 send
-rwxr-xr-x 1 root root 80213 Aug 20 15:52 sendEmail
-rwxr-xr-x 1 root root   204 Aug 20 15:53 testpl
(4) 修改脚本
[root@db03 /usr/local/bin]# vim testpl 
#!/bin/bash
/usr/local/bin/sendEmail -o tls=no -f lichenxing0430@163.com -t 245684979@qq.com -s smt
p.163.com:25 -xu lichenxing0430 -xp <passworld> -u "MHA Waring" -m "YOUR MHA MAY BE F
AILOVER ,发送成功!" &>/tmp/sendmail.log
(5)停止MHA
masterha_stop --conf=/etc/mha/app1.cnf
(6)开启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 &
(7) 发送邮件
[root@db03 /usr/local/bin]# ./testpl 


####(8) 关闭主库,看警告邮件(db02)

[root@db02 ~]# pkill mysqld

(9) 查看vip并收到邮件


(10) 故障恢复(db03)

mysql -e "change master to master_host='10.0.0.51',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;"

mysql -e  "start slave;"

mysql -e  "show slave status \G"|grep "Running:"

3. binlog server(db03)

3.1 添加配置文件
vim /etc/mha/app1.cnf 

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog
3.2 创建必要目录
mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*
3.3 拉取主库binlog日志
cd /data/mysql/binlog

mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &
3.4 重启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 &

故障处理
主库宕机,binlogserver 自动停掉,manager 也会自动停止。
处理思路:
1、重新获取新主库的binlog到binlogserver中
2、重新配置文件binlog server信息
3、最后再启动MHA

3.管理员在高可用架构维护的职责

  1. 搭建:MHA+VIP+SendReport+BinlogServer
  2. 监控及故障处理
  3. 高可用架构的优化
    核心是:尽可能降低主从的延时,让MHA花在数据补偿上的时间尽量减少。
    5.7 版本,开启GTID模式,开启从库SQL并发复制。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值