优酷土豆资深工程师:MySQL高可用之MaxScale与MH

debugjoker 2016-07-29

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

本文根据DBAplus社群第67期线上分享整理而成,文末还有书送哦~

讲师介绍

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

侯野

优酷土豆资深数据库工程师

  • 擅长Orale、MySQL故障诊断、性能调优,目前专注于MySQL的高可用技术。

  • 曾任职于大连东软、清华紫光、触控科技等公司,服务过华夏银行、中国华能电力集团,担任OracleDBA、Oracle高级咨询顾问。

本次分享主要包括以下内容:

1、MySQL高可用方案

2、为什么选择MHA

3、读写分离方案的寻找以及为什么选择Maxscale

一、MySQL Failover的方案

常见的Failover方案

  • MMM

MMM缺点:

  1. Monitor节点是单点,可以结合Keepalived实现高可用目前MySQL Failover 的方案

  2. Keepalived会有脑裂的风险

  3. 在读写繁忙的业务中可能丢数据

  4. MHA + ssh -o 测试心跳 + masterMHA_secondary_check(两次检测)

  • MHA

MHA优点:

  1. 从宕机崩溃的Master保存二进制日志事件(binlogevent)

  2. 识别含有最新更新的Slave

  3. 应用差异的中继日志(relaylog)到其他Slave

  4. 应用从Master保存的二进制日志事件

  5. 提升一个Slave为新的Master

  6. 使其他的Slave连接新的Master进行复制

  7. MariaDB Replication Manager (MRM)

只支持MariaDB with GTID based replication topologies

二、MHA

今天主要说下MHA。MHA可以说是强一致的主从切换工具 ,而且切换间隔小于30s,非常适合在线上使用。

具体原理

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

  1. 从宕机崩溃的Master保存二进制日志事件(binlogevent)

  2. 识别含有最新更新的Slave

  3. 应用差异的中继日志(relaylog)到其他Slave

  4. 应用从Master保存的二进制日志事件

  5. 提升一个Slave为新的Master

  6. 使其他的Slave连接新的Master进行复制

MHA组成

rpm -ql MHA4MySQL-manager-0.56-0.el6.noarch

1、管理节点

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

2、数据节点

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

3、MySQL的配置要点

安装配置MHA

1)MySQL主从

MySQL一主两从(一个candidate_master)

master:

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

slave:

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

MySQL主从搭建 (一主两从)

1)MySQL主从配置

  • 创建用户

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

  • 备份

MySQLdump --master-data=2 --single-transaction -A > bk.sql (我们生产上不允许使用函数和存储过程)

Tips:如果不是新建db,建议使用mydumper(slave)或者innobackupex(master) 备份

  • 从库执行

a.将bk.sql 在从库恢复

b.执行

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

c.如果开启GTID

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

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)编辑文件

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

4)清理relay log

slave上的relay_log_purge是关闭的,在MHA环境中,failover时,会用到relay log来对比差异日志,将差异日志发送到其他slave上,进行回放

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

5、MHA环境监测

检查MHA环境

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

启动MHA manager

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

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:

  1. MHA默认没有arping,这个要自己加上,否则服务器会自动等到vip缓存失效,期间VIP会有一定时间的不可用

  2. masterha_manager 命令行中加入--ignore_last_failover 否则再次切换会失败,除非删除app1.failover.complete文件

  3. vip 我们没有使用keepalive,是在两个主机上插网线, 如eth1,将vip加到 master 的eth1上

  4. 要将备主的对应网卡激活

  5. report_script=/usr/bin/send_report 发邮件的功能要加上

  6. slave不要延迟过长,延迟越久,切换也越久

  7. 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)

  8. grep -i 'change master' manager.log 可以找到change master to 语句 ,可以在切换后旧的主库上执行

  9. 设置 ignore_fail = 1 这样即使slave 有错误,也会切换

  10. 设置ssh 的 timeout 防止ssh连接慢时,MHA发生切换

7、MHA manager 管理多实例

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

这样就完成多实例的部署。

Tips:

如果觉得MHA部署麻烦,还要自己写脚本,可以使用MHA_helper

web:https://github.com/ovaistariq/MHA-helper

SQL-aware负载均衡器:

  1. MySQL proxy:官方不维护了

  2. MySQL Router:官方维护,比较简单

  3. MaxScale:插件式,定制灵活,自动检测MySQL master failure

  4. Amoeba:支持sql过滤,读写分离,sharding,不支持 MySQL Failover

  5. Cobar:支持分库,不支持分表

  6. MyCat:基于Cobar的二次开发

  7. TDDL(Taobao Distributed Data Layer):阿里自研的基于client模式的读写分离的中间件

三、Maxscale

这里想要介绍的是Maxscale。

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

Maxscale有哪些优点呢,一句话,上面这些中间件有的优点,它基本都有。

  1. 带权重的读写分离(负载均衡)

  2. SQL防火墙

  3. 多种路由策略(Connection based, Statement based,Schema based)

  4. 自动检测MySQL master Failover (配合MHA或者MRM)

  5. 检测主从延时

  6. 多租户sharding架构

架构比较

大多数互联网公司的db架构

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

隐患:一般的互联网公司会使用MHA做Failover , 然后使用LVS在读库上做负载均衡,但是LVS走的TCP协议,当read 库挂掉,LVS也不会将其踢掉,另外LVS对长连接的应用支持的不好, 因为由于LVS的检查时长一般在30s, 但是长连接的设置一般都是30分钟,或者不设置timwout,这样,当业务端 断开连接后,LVS还认为它会死活着的, 所以 连接到db的thread却并不减少。造成thead_connected 打满,MySQL不可用。

使用Maxscale的db层架构

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

规避了使用LVS时候的长链接超时不断开问题。

Maxscale配置很简单

  1. yum -y install Maxscale (只在Maxscale上执行)

  2. cp MaxScale_template.cnf Maxscale.cnf

  3. 生成密码:

    maxkeys /var/lib/maxscale/

    maxpasswd /var/lib/maxscale/ maven119

  4. 修改配置文件

    需要的单独找我吧,太长了配置文件……

通过管理命令,查看状态

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

可以看到目前有两台db,以及运行状态

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

看到开启了什么服务读写分离和client

下面来做一下结单的测试:

MySQL master节点:

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

4 rows in set (0.00 sec)

MySQL slave节点,多增加一条记录。

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

发现读打在了从库。

如果想让读搭载主库上 ,可以把select语句放到事务中。

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

具体的读写情况可以使用general_log观察。

在 master 节点执行 :

set global general_log=1;

在Maxscale节点执行 :

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

发现写打在了主库上。

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

Tips:

  1. 如果想要在master上读

  2. 可以把select语句放到事务中begin;select;commit

  3. Maxscale会对每个slave做健康检查,原理与pt-heartbeat一样的。主库插入时间戳,到slave与serevr时间对比。

  4. gnoring secrets file /var/lib/maxscale/.secrets, invalid permissions .secrets的权限不对 chown maxscale:maxscale .secrets

  5. Maxscale 1.4版本做了很多的改进

重要概念DCB

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

从这种图中可以看出来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这两个不能配。

好书相送

在本文微信评论区留下足以引起共鸣的真知灼见,并在本文发布后32小时之内成为点赞数最多的前2名,可获得以下书籍一本~

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

特别鸣谢清华大学出版社为本次活动提供图书赞助。

精选专题(点击蓝色标题可阅读全文)

近期活动:

Gdevops全球敏捷运维峰会广州站

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

峰会官网:www.gdevops.com

优酷土豆资深工程师:MySQL高可用之MaxScale与MH

相关推荐