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

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:
讲师介绍
 
侯野
优酷土豆资深数据库工程师
 
  • 擅长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,非常适合在线上使用。


具体原理
 

  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、管理节点



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:

  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 管理多实例



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


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。



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


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

  2. SQL防火墙

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

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

  5. 检测主从延时

  6. 多租户sharding架构


架构比较


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


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


使用Maxscale的db层架构



规避了使用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. 修改配置文件

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


通过管理命令,查看状态



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


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


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


MySQL master节点:



4 rows in set (0.00 sec)


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


发现读打在了从库。


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



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


在 master 节点执行 :


set global general_log=1;


在Maxscale节点执行 :


发现写打在了主库上。



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



从这种图中可以看出来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

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
7月前
|
SQL 容灾 关系型数据库
rds容灾与高可用
rds容灾与高可用
107 4
|
7月前
|
存储 关系型数据库 MySQL
Mysql高可用|索引|事务 | 调优
Mysql高可用|索引|事务 | 调优
|
1月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
122 3
Mysql高可用架构方案
|
4月前
|
运维 容灾 关系型数据库
MySQL高可用方案--Xenon全解
MySQL高可用方案--Xenon全解
|
4月前
|
SQL 关系型数据库 MySQL
orchestrator搭建mysql高可用
orchestrator搭建mysql高可用
51 0
|
4月前
|
缓存 关系型数据库 MySQL
如何实现mysql高可用集群
如何实现mysql高可用集群
47 0
|
6月前
|
运维 容灾 关系型数据库
介绍几种 MySQL 官方高可用方案
MySQL 官方提供了多种高可用部署方案,从最基础的主从复制到组复制再到 InnoDB Cluster 等等。本篇文章以 MySQL 8.0 版本为准,介绍下不同高可用方案架构原理及使用场景。
1313 3
介绍几种 MySQL 官方高可用方案
|
4月前
|
安全 关系型数据库 MySQL
【MySQL】Orchestrator最简单的 mysql 高可用方案最细细细细~
【MySQL】Orchestrator最简单的 mysql 高可用方案最细细细细~
|
4月前
|
缓存 关系型数据库 MySQL
MySQL调优秘籍曝光!从索引到事务,全方位解锁高可用秘诀,让你的数据库性能飞起来!
【8月更文挑战第6天】MySQL是顶级关系型数据库之一,其性能直接影响应用的高可用性与用户体验。本文聚焦MySQL的高性能调优,从索引设计到事务管理,逐一解析。介绍如何构建高效索引,如联合索引`CREATE INDEX idx_order_customer ON orders(order_id, customer_id);`,以及索引覆盖查询等技术。
81 0
|
6月前
|
SQL 关系型数据库 MySQL
MySQL高可用架构设计:从主从复制到分布式集群
MySQL高可用性涉及主从复制、半同步复制和Group/InnoDB Cluster。主从复制通过二进制日志同步数据,保证故障时可切换。半同步复制确保事务在至少一个从服务器确认后才提交。Group Replication是多主复制,支持自动故障切换。InnoDB Cluster是8.0的集成解决方案,简化集群管理。使用这些技术能提升数据库的稳定性和可靠性。
518 2