擅长Orale、MySQL故障诊断、性能调优，目前专注于MySQL的高可用技术。
曾任职于大连东软、清华紫光、触控科技等公司，服务过华夏银行、中国华能电力集团，担任OracleDBA、Oracle高级咨询顾问。
本次分享主要包括以下内容：
1、MySQL高可用方案
2、为什么选择MHA
3、读写分离方案的寻找以及为什么选择Maxscale
一、MySQL Failover的方案
常见的Failover方案
MMM
MMM缺点：
Monitor节点是单点，可以结合Keepalived实现高可用目前MySQL Failover 的方案
Keepalived会有脑裂的风险
在读写繁忙的业务中可能丢数据
MHA + ssh -o 测试心跳 + masterMHA_secondary_check(两次检测)
MHA
MHA优点：
从宕机崩溃的Master保存二进制日志事件(binlogevent)
识别含有最新更新的Slave
应用差异的中继日志(relaylog)到其他Slave
应用从Master保存的二进制日志事件
提升一个Slave为新的Master
使其他的Slave连接新的Master进行复制
MariaDB Replication Manager (MRM)
只支持MariaDB with GTID based replication topologies
二、MHA
今天主要说下MHA。MHA可以说是强一致的主从切换工具 ，而且切换间隔小于30s，非常适合在线上使用。
从宕机崩溃的Master保存二进制日志事件(binlogevent)
识别含有最新更新的Slave
应用差异的中继日志(relaylog)到其他Slave
应用从Master保存的二进制日志事件
提升一个Slave为新的Master
使其他的Slave连接新的Master进行复制
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：
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 -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)
grep -i 'change master' manager.log 可以找到change master to 语句 ，可以在切换后旧的主库上执行
设置 ignore_fail = 1 这样即使slave 有错误，也会切换
设置ssh 的 timeout 防止ssh连接慢时，MHA发生切换
7、MHA manager 管理多实例
这样就完成多实例的部署。
Tips：
如果觉得MHA部署麻烦，还要自己写脚本，可以使用MHA_helper
web:https://github.com/ovaistariq/MHA-helper
SQL-aware负载均衡器：
MySQL proxy：官方不维护了
MySQL Router：官方维护，比较简单
MaxScale：插件式，定制灵活，自动检测MySQL master failure
Amoeba：支持sql过滤，读写分离，sharding，不支持 MySQL Failover
Cobar：支持分库，不支持分表
MyCat：基于Cobar的二次开发
TDDL(Taobao Distributed Data Layer)：阿里自研的基于client模式的读写分离的中间件
三、Maxscale
这里想要介绍的是Maxscale。
Maxscale有哪些优点呢，一句话，上面这些中间件有的优点，它基本都有。
带权重的读写分离(负载均衡)
SQL防火墙
多种路由策略(Connection based， Statement based，Schema based)
自动检测MySQL master Failover (配合MHA或者MRM)
检测主从延时
多租户sharding架构
架构比较
大多数互联网公司的db架构
隐患：一般的互联网公司会使用MHA做Failover ， 然后使用LVS在读库上做负载均衡，但是LVS走的TCP协议，当read 库挂掉，LVS也不会将其踢掉，另外LVS对长连接的应用支持的不好， 因为由于LVS的检查时长一般在30s， 但是长连接的设置一般都是30分钟，或者不设置timwout，这样，当业务端 断开连接后，LVS还认为它会死活着的， 所以 连接到db的thread却并不减少。造成thead_connected 打满，MySQL不可用。
使用Maxscale的db层架构
规避了使用LVS时候的长链接超时不断开问题。
Maxscale配置很简单
yum -y install Maxscale (只在Maxscale上执行)
cp MaxScale_template.cnf Maxscale.cnf
生成密码：
maxkeys /var/lib/maxscale/
maxpasswd /var/lib/maxscale/ maven119
修改配置文件
需要的单独找我吧，太长了配置文件……
通过管理命令，查看状态
可以看到目前有两台db，以及运行状态
看到开启了什么服务读写分离和client
下面来做一下结单的测试：
MySQL master节点：
4 rows in set (0.00 sec)
MySQL slave节点，多增加一条记录。
发现读打在了从库。
如果想让读搭载主库上 ，可以把select语句放到事务中。
具体的读写情况可以使用general_log观察。
在 master 节点执行 ：
set global general_log=1;
在Maxscale节点执行 ：
发现写打在了主库上。
Tips:
如果想要在master上读
可以把select语句放到事务中begin;select;commit
Maxscale会对每个slave做健康检查，原理与pt-heartbeat一样的。主库插入时间戳，到slave与serevr时间对比。
gnoring secrets file /var/lib/maxscale/.secrets, invalid permissions .secrets的权限不对 chown maxscale:maxscale .secrets
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和端口即可。
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
