优酷土豆资深工程师:MySQL高可用之MaxScale与MHA
本文根据DBAplus社群第67期线上分享整理而成
本次分享主要包括以下内容:
1、MySQL高可用方案
2、为什么选择MHA
3、读写分离方案的寻找以及为什么选择Maxscale
一、MySQL Failover的方案
常见的Failover方案
-
MMM
MMM缺点:
-
Monitor节点是单点,可以结合Keepalived实现高可用目前MySQL Failover 的方案
-
Keepalived会有脑裂的风险
-
在读写繁忙的业务中可能丢数据
-
MHA + ssh -o 测试心跳 + masterMHA_secondary_check(两次检测)
-
MHA
MHA优点:
-
从宕机崩溃的Master保存二进制日志事件(binlogevent)
-
识别含有最新更新的Slave
-
应用差异的中继日志(relaylog)到其他Slave
-
应用从Master保存的二进制日志事件
-
提升一个Slave为新的Master
-
使其他的Slave连接新的Master进行复制
-
MariaDB Replication Manager (MRM)
只支持MariaDB with GTID based replication topologies
二、MHA
今天主要说下MHA。MHA可以说是强一致的主从切换工具 ,而且切换间隔小于30s,非常适合在线上使用。
具体原理
-
从宕机崩溃的Master保存二进制日志事件(binlogevent)
-
识别含有最新更新的Slave
-
应用差异的中继日志(relaylog)到其他Slave
-
应用从Master保存的二进制日志事件
-
提升一个Slave为新的Master
-
使其他的Slave连接新的Master进行复制
MHA组成
rpm -ql MHA4MySQL-manager-0.56-0.el6.noarch
1、管理节点
2、数据节点
3、MySQL的配置要点
安装配置MHA
1)MySQL主从
MySQL一主两从(一个candidate_master)
master:
slave:
MySQL主从搭建 (一主两从)
1)MySQL主从配置
-
创建用户
-
备份
MySQLdump --master-data=2 --single-transaction -A > bk.sql (我们生产上不允许使用函数和存储过程)
Tips:如果不是新建db,建议使用mydumper(slave)或者innobackupex(master) 备份
-
从库执行
a.将bk.sql 在从库恢复
b.执行
c.如果开启GTID
Tips:
1、降低数据丢失风险
innodb_flush_log_at_trx_commit=1
innodb_support_xa=1
sync_binlog =1
gtid
半同步复制或者5.7的增强半同步
binlog_format 为RBR
2、主从一致检测
pt-table-checksum
pt-table-sync
pt-online-schema-change 虽然5.6 支持ddl online ,我还是建议使用pt-osc ,但是注意:如果binlog_format为SBR , 使用pt-osc 会有主键冲突的风险
4、MHA配置
1)ssh 配置
ansible 来做
2)安装MHA
yum install -y --nogpgcheck MHA4MySQL-*(已经下载好了) 在每个节点都执行
3)编辑文件
4)清理relay log
slave上的relay_log_purge是关闭的,在MHA环境中,failover时,会用到relay log来对比差异日志,将差异日志发送到其他slave上,进行回放
5、MHA环境监测
检查MHA环境
启动MHA manager
6、MHA切换测试
1)模拟实例cresh
/etc/init.d/MySQL stop
2)模拟主机cresh
echo a > /proc/sysrq-trigger
3)使用iptables
iptables -A INPUT -p tcp -m iprange --src-range 192.168.10.1-192.168.10.241 --d port 3306 -j DROP
PS.可以在master节点跑sysbench,在压测的过程中来做以上测试
Tips:
-
MHA默认没有arping,这个要自己加上,否则服务器会自动等到vip缓存失效,期间VIP会有一定时间的不可用
-
masterha_manager 命令行中加入--ignore_last_failover 否则再次切换会失败,除非删除app1.failover.complete文件
-
vip 我们没有使用keepalive,是在两个主机上插网线, 如eth1,将vip加到 master 的eth1上
-
要将备主的对应网卡激活
-
report_script=/usr/bin/send_report 发邮件的功能要加上
-
slave不要延迟过长,延迟越久,切换也越久
-
secondary_check_script=/usr/local/bin/masterha_secondary_check -s 192.168.10.100 -s 192.168.10.101 --user=root --master_host=maven119 --master_ip=192.168.10.88 --master_port=3306 这样只有当两个manager都ping不通才会切换,防止数据不一致(注意修改masterha_secondary_check 中ssh的端口号,他是写死的22)
-
grep -i 'change master' manager.log 可以找到change master to 语句 ,可以在切换后旧的主库上执行
-
设置 ignore_fail = 1 这样即使slave 有错误,也会切换
-
设置ssh 的 timeout 防止ssh连接慢时,MHA发生切换
7、MHA manager 管理多实例
这样就完成多实例的部署。
Tips:
如果觉得MHA部署麻烦,还要自己写脚本,可以使用MHA_helper
web:https://github.com/ovaistariq/MHA-helper
SQL-aware负载均衡器:
-
MySQL proxy:官方不维护了
-
MySQL Router:官方维护,比较简单
-
MaxScale:插件式,定制灵活,自动检测MySQL master failure
-
Amoeba:支持sql过滤,读写分离,sharding,不支持 MySQL Failover
-
Cobar:支持分库,不支持分表
-
MyCat:基于Cobar的二次开发
-
TDDL(Taobao Distributed Data Layer):阿里自研的基于client模式的读写分离的中间件
三、Maxscale
这里想要介绍的是Maxscale。
Maxscale有哪些优点呢,一句话,上面这些中间件有的优点,它基本都有。
-
带权重的读写分离(负载均衡)
-
SQL防火墙
-
多种路由策略(Connection based, Statement based,Schema based)
-
自动检测MySQL master Failover (配合MHA或者MRM)
-
检测主从延时
-
多租户sharding架构
架构比较
大多数互联网公司的db架构
隐患:一般的互联网公司会使用MHA做Failover , 然后使用LVS在读库上做负载均衡,但是LVS走的TCP协议,当read 库挂掉,LVS也不会将其踢掉,另外LVS对长连接的应用支持的不好, 因为由于LVS的检查时长一般在30s, 但是长连接的设置一般都是30分钟,或者不设置timwout,这样,当业务端 断开连接后,LVS还认为它会死活着的, 所以 连接到db的thread却并不减少。造成thead_connected 打满,MySQL不可用。
使用Maxscale的db层架构
规避了使用LVS时候的长链接超时不断开问题。
Maxscale配置很简单
-
yum -y install Maxscale (只在Maxscale上执行)
-
cp MaxScale_template.cnf Maxscale.cnf
-
生成密码:
maxkeys /var/lib/maxscale/
maxpasswd /var/lib/maxscale/ maven119
-
修改配置文件
需要的单独找我吧,太长了配置文件……
通过管理命令,查看状态
可以看到目前有两台db,以及运行状态
看到开启了什么服务读写分离和client
下面来做一下结单的测试:
MySQL master节点:
4 rows in set (0.00 sec)
MySQL slave节点,多增加一条记录。
发现读打在了从库。
如果想让读搭载主库上 ,可以把select语句放到事务中。
具体的读写情况可以使用general_log观察。
在 master 节点执行 :
set global general_log=1;
在Maxscale节点执行 :
发现写打在了主库上。
Tips:
-
如果想要在master上读
-
可以把select语句放到事务中begin;select;commit
-
Maxscale会对每个slave做健康检查,原理与pt-heartbeat一样的。主库插入时间戳,到slave与serevr时间对比。
-
gnoring secrets file /var/lib/maxscale/.secrets, invalid permissions .secrets的权限不对 chown maxscale:maxscale .secrets
-
Maxscale 1.4版本做了很多的改进
重要概念DCB
从这种图中可以看出来DCB的重要性了,callback 最后走到了 dcb.h
那么什么是DCB呢?
一个DCB(Descriptor Control Block)表示一个在MaxScale内部的连接的状态,每个来自client的连接、到后端server的连接、以及每个listener都会被分配一个DCB,这些连接的状态统计由这些DCB来完成。每个DCB并不会有特定的名字用于查询,而是直接使用具有唯一性的内存地址。
Maxscale的MHA
官方推荐使用Lsyncd或者Corosync-Pacemaker。
个人认为Maxscale的一些想法是不错的,包括Percona也生成Maxscale是目前最好的读写分离中间件。目前还不是很成熟,小项目可以试试。大型项目还是推荐TDDL这种经过生产实践的中间件。
Maxscale与MHA整合
Maxscale与MHA整合其实非常简单,一般MHA都会让 开发使用vip。master宕掉后,slave接管,对前端是透明的。
在与Maxscale结合的时候,Maxscale.conf文件不需要改变任何东西,只需要在后端将MHA部署上就可以。因Maxscale可以监控MySQL的主从变更。
总结:Maxscale与MHA整合,只需要安装MHA即可。
写在最后,对已有的MySQL主从环境上MHA和Maxscale几乎不需要更改任何配置。只需要更改开发框架中的配置 ,把原IP和端口改写为Maxscale server的IP和端口即可。
Q&A
Q1:请问,这个10.10.111.1是部署Maxscale服务器的物理IP吗,部署Maxscale的服务器是不是也需要两台服务器做HA?就一台服务器的话要是意外宕机岂不是会导致整个应用瘫痪?还是说我理解错了?
A1:官方推荐使用Lsyncd或者Corosync-Pacemaker做Maxscale的HA。
Q2:监控系统是自主研发的还是采用开源的?都是以哪些为监控指标来监控性能和稳定性的?
A2:pt-heartbeat来实时监控主从状态,pt-heartbeat可以一秒。
Q3:一直不明白挺好的东西为啥不用,非要主从之间切来切去?
A3:可能场景不同,我们一般都会有4台db做Master-slave,主要是需要扩容读库。优酷基本上是读大于写。
Q4:slave-skip-errors = 1062,1032,1060这类配置你们用吗?
A4:用。但是1062,1032这两个不能配。
好书相送
在本文微信评论区留下足以引起共鸣的真知灼见,