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

讲师介绍 优酷土豆资深工程师:MySQL高可用之MaxScale与MHA侯野优酷土豆资深数据库工程师 
  • 擅长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与MHA

  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与MHA


2、数据节点


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


3、MySQL的配置要点


安装配置MHA


1)MySQL主从


MySQL一主两从(一个candidate_master)


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


slave:


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


MySQL主从搭建 (一主两从)


1)MySQL主从配置


  • 创建用户


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


  • 备份


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


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


  • 从库执行


a.将bk.sql 在从库恢复


b.执行 


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


c.如果开启GTID


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


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与MHA

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


4)清理relay log


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


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


5、MHA环境监测


检查MHA环境


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


启动MHA manager


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

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与MHA


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


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与MHA


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


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

  2. SQL防火墙

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

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

  5. 检测主从延时

  6. 多租户sharding架构


架构比较


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


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

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


使用Maxscale的db层架构


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


规避了使用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与MHA


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


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

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


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


MySQL master节点:


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


4 rows in set (0.00 sec)


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

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


发现读打在了从库。


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


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


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


在 master 节点执行 :


set global general_log=1;


在Maxscale节点执行 :


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

发现写打在了主库上。


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


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与MHA


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


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2016-07-29

上一篇:sql server 高可用日志传送


下一篇:[Step By Step]SAP HANA PAL 数据处理抽样算法Sampling实例SAMPLING