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

本文根据DBAplus社群第67期线上分享整理而成

 

本次分享主要包括如下内容：

一、MySQL高可用方案

二、为何选择MHA

三、读写分离方案的寻找以及为何选择Maxscale

 

1、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

 

2、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

 

一、管理节点

 

 

 

二、数据节点

 

 

 

三、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:

一、下降数据丢失风险

innodb_flush_log_at_trx_commit=1

innodb_support_xa=1

sync_binlog =1

gtid

半同步复制或者5.7的加强半同步

binlog_format 为RBR

 

二、主从一致检测

pt-table-checksum 

pt-table-sync

pt-online-schema-change 虽然5.6 支持ddl online ,我仍是建议使用pt-osc ,可是注意：若是binlog_format为SBR , 使用pt-osc 会有主键冲突的风险

 

四、MHA配置

 

1）ssh 配置

ansible 来作

 

2）安装MHA

yum install -y --nogpgcheck MHA4MySQL-*(已经下载好了) 在每一个节点都执行

 

3）编辑文件

 

 

 

 

 

4）清理relay log

 

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

 

 

 

五、MHA环境监测

 

检查MHA环境

 

 

 

启动MHA manager

 

 

六、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发生切换

 

七、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模式的读写分离的中间件

 

3、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这两个不能配。

好书相送

在本文微信评论区留下足以引发共鸣的真知灼见，