UDN-企业互联网技术人气社区

板块导航

浏览  : 1233
回复  : 1

[讨论交流] 优酷土豆资深工程师:MySQL高可用之MaxScale与MHA(有彩蛋)

[复制链接]
瞌睡虫的头像 楼主
发表于 2016-8-10 08:55:08 | 显示全部楼层 |阅读模式
  本次分享主要包括以下内容:

  1、MySQL高可用方案

  2、为什么选择MHA

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

  一、MySQLFailover的方案

  常见的Failover方案

  MMM

  MMM缺点:

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

  Keepalived会有脑裂的风险

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

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

  MHA

  MHA优点:

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

  识别含有最新更新的Slave

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

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

  提升一个Slave为新的Master

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

  MariaDBReplicationManager(MRM)

  只支持MariaDBwithGTIDbasedreplicationtopologies

  二、MHA

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

  具体原理

  
1.webp.jpg


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

  识别含有最新更新的Slave

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

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

  提升一个Slave为新的Master

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

  MHA组成

  rpm-qlMHA4MySQL-manager-0.56-0.el6.noarch

  1、管理节点

  
2.webp.jpg


  2、数据节点

  
3.webp.jpg


  3、MySQL的配置要点

  安装配置MHA

  1)MySQL主从

  MySQL一主两从(一个candidate_master)

  master:

  
4.webp.jpg


  slave:

5.webp.jpg

  MySQL主从搭建(一主两从)

  1)MySQL主从配置

  创建用户

  
6.webp.jpg


  备份

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

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

  从库执行

  a.将bk.sql在从库恢复

  b.执行

  
7.webp.jpg


  c.如果开启GTID

  
8.webp.jpg


  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支持ddlonline,我还是建议使用pt-osc,但是注意:如果binlog_format为SBR,使用pt-osc会有主键冲突的风险

  4、MHA配置

  1)ssh配置

  ansible来做

  2)安装MHA

  yuminstall-y--nogpgcheckMHA4MySQL-*(已经下载好了)在每个节点都执行

  3)编辑文件

  
9.webp.jpg


  
10.webp.jpg


  4)清理relaylog

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

  
11.webp.jpg


  5、MHA环境监测

  检查MHA环境

  
12.webp.jpg


  启动MHAmanager

  
13.webp.jpg


  6、MHA切换测试

  1)模拟实例cresh

  /etc/init.d/MySQLstop

  2)模拟主机cresh

  echoa>/proc/sysrq-trigger

  3)使用iptables

  iptables-AINPUT-ptcp-miprange--src-range192.168.10.1-192.168.10.241--dport3306-jDROP

  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-s192.168.10.100-s192.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'changemaster'manager.log可以找到changemasterto语句,可以在切换后旧的主库上执行

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

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

  7、MHAmanager管理多实例

  
14.webp.jpg


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

  Tips:

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

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

  SQL-aware负载均衡器:

  MySQLproxy:官方不维护了

  MySQLRouter:官方维护,比较简单

  MaxScale:插件式,定制灵活,自动检测MySQLmasterfailure

  Amoeba:支持sql过滤,读写分离,sharding,不支持MySQLFailover

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

  MyCat:基于Cobar的二次开发

  TDDL(TaobaoDistributedDataLayer):阿里自研的基于client模式的读写分离的中间件

  三、Maxscale

  这里想要介绍的是Maxscale。

  
15.jpg


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

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

  SQL防火墙

  多种路由策略(Connectionbased,Statementbased,Schemabased)

  自动检测MySQLmasterFailover(配合MHA或者MRM)

  检测主从延时

  多租户sharding架构

  架构比较

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

  
16.webp.jpg


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

  使用Maxscale的db层架构

  
17.webp.jpg


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

  Maxscale配置很简单

  yum-yinstallMaxscale(只在Maxscale上执行)

  cpMaxScale_template.cnfMaxscale.cnf

  生成密码:

  maxkeys/var/lib/maxscale/

  maxpasswd/var/lib/maxscale/maven119

  修改配置文件

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

  通过管理命令,查看状态

  
18.webp.jpg


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

  
19.webp.jpg


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

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

  MySQLmaster节点:

  
20.webp.jpg


  4rowsinset(0.00sec)

  MySQLslave节点,多增加一条记录。

  
21.webp.jpg


  发现读打在了从库。

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

  
22.webp.jpg


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

  在master节点执行:

  setglobalgeneral_log=1;

  在Maxscale节点执行:

  
23.webp.jpg


  发现写打在了主库上。

  
24.webp.jpg


  Tips:

  如果想要在master上读

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

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

  gnoringsecretsfile/var/lib/maxscale/.secrets,invalidpermissions.secrets的权限不对chownmaxscale:maxscale.secrets

  Maxscale1.4版本做了很多的改进

  重要概念DCB

  从这种图中可以看出来DCB的重要性了,callback最后走到了dcb.h

  那么什么是DCB呢?

  一个DCB(DescriptorControlBlock)表示一个在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和端口改写为Maxscaleserver的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-8-10 11:19:34 | 显示全部楼层
对已有的MySQL主从环境上MHA和Maxscale几乎不需要更改任何配置。只需要更改开发框架中的配置,把原IP和端口改写为Maxscaleserver的IP和端口即可。
使用道具 举报

回复

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部