小谈 MySQL 第七话·高可用架构（Mycat+MHA+LVS）

目录

一、初始 Mycat+MHA+LVS

1、为什么选择 Mycat？

2、为什么选择 MHA？

3、为什么选择 LVS？

二、Mycat 架构

1、用 Mycat 搭建读写分离

2、用 Mycat 实现分库分表

三、MHA 架构  

1、MHA 工作原理

2、MHA 优点

---

一、初始 Mycat+MHA+LVS

1、为什么选择 Mycat？

互联网的高速发展使分布式技术兴起，当系统的压力越来越大时，人们首先想到的解决方案就是向上扩展（scale up），简单说就是不断增加硬件性能来解决这个问题，采用这种方案的硬件成本比较高。还有另外一种方案就是水平扩展，通过增加服务器的节点采用负载均衡来解决问题，这样在应用服务器层面我们可以不停地增加服务器，来满足高并发和高访问量。这里我们只需要考虑 session 的处理，所有的压力都会指向数据库，数据库却不能新增节点来完成扩容，必须采用其它方式来实现。

这时各种分布式数据库中间件应用而生，出现了很多解决方案，比如 amoeba、atlas、cobar、mycat、mysql proxy 等，而 Mycat 是目前开源数据库中间件中非常成熟的解决方案，社区也非常活跃。

对比项目	Mycat	Mango	Cobar	Heisenberg	Altas	Amoeba
数据切片	支持	支持	支持	支持	支持	支持
读写分离	支持	支持	支持	支持	支持	支持
宕机自动切换	支持	不支持	支持	不支持	半支持，影响写	不支持
MySQL 协议	前后端支持	JDBC	前端支持	前后端支持	前后端支持	JDBC
支持的数据库	MySQL、Oracle、MongoDB、postgresql	MySQL	MySQL	MySQL	MySQL	MySQL、MongoDB
社区活跃度	高	活跃	停滞	低	中等	停滞
文档资料	极丰富	较齐全	较齐全	缺少	中等	缺少
是否开源	开源	开源	开源	开源	开源	开源
是否支持事务	支持分布式事务（弱 XA）	支持	单库强一致、分布式弱事务	单库强一致、分布式弱事务	单库强一致、分布式弱事务	不支持

2、为什么选择 MHA？

MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，是一套优秀的作为 MySQL 高可用环境下故障切换和主从提升的高可用软件（是采用 Perl 语言编写的一个实现 MySQL 高可用方案的脚本管理工具）。在 MySQL 故障切换过程中，MHA 能做到 10~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中，MHA 能在最大程度上保证数据的一致性，已达到真正意义上的高可用。

3、为什么选择 LVS？

LVS 是使用 Linux 内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

优点：

• 抗负载能力强、是工作在网络 4 层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和 cpu 资源消耗比较低。
• 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
• 工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如 LVS + Keepalived。
• 无流量，LVS 只分发请求，而流量并不从它本身出去，这点保证了均衡器 IO 的性能不会受到大流量的影响。
• 应用范围比较广，因为 LVS 工作在 4 层，所以它几乎可以对所有应用做负载均衡，包括 http、数据库、在线聊天室等等。

缺点：

• 软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是 Nginx/HAProxy + Keepalived 的优势所在。
• 如果是网站应用比较庞大的话，LVS/DR + Keepalived 实施起来就比较复杂了，特别后面有 Windows Server 的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy + Keepalived 就简单多了。

二、Mycat 架构

1、用 Mycat 搭建读写分离

读写分离，简单地说是把对数据的读和写操作分开，以对应不同的数据库服务器。主数据库提供写操作，从数据库提供读操作，这样能有效的减轻单台数据库的压力。

2、用 Mycat 实现分库分表

Mycat 位于应用与数据库的中间层，可以灵活解耦应用与数据库，后端数据库可以位于不同的主机上。在 Mycat 中将分表分为两种大的感念：对于数据量小且不需要做数据切片的表称之为非分片表；对于数据量大到单库性能、容量、不足以支撑，数据需要通过水平切分均匀分布到不同的数据库中的表，称之为分片表。而中间件最终需要处理的事情是对数据切分、聚合。

三、MHA 架构  

MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，MHA Node运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其它的 slave 重新指向新的 master。

在 MHA 自动故障切换过程中，MHA 试图从宕机的主服务器上保存的二进制日志，最大程度地保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过 ssh 访问，MHA 没法保存二进制日志，只进行故障转移而丢失了最新数据。MHA 可以与半同步复制结合起来降低数据丢失的风险。

目前 MHA 主要支持一主多从的架构，要搭建 MHA，要求一个复制集群中必须最少有三台数据库服务器，一主两从，即一台充当 master，一台充当备用 master，另一台充当从库。

1、MHA 工作原理

① 从宕机崩溃的 master 保存二进制日志事件；

② 识别含有最新更新的 slave；

③ 应用差异的中继日志（relay log）到其它slave；

④ 应用从 master 保存的二进制日志事件；

⑤ 提升一个 slave 为新的 master；

⑥ 使其它的 slave 连接到新的 master 进行复制；

2、MHA 优点

① 自动监控 master，故障转移的速度很快（在 9~12 秒内可以检测到 master 故障；7~10 秒内可以关闭 master 机器以避免脑裂；在几秒内可以应用差异日志，并构建新的主从架构。整个过程可以在 10~30秒内完成，可最大化地减少故障修复时间）；

② master 宕机时可以最大化地减少数据的丢失（当 master 宕机时，MHA 会自动检测和选择数据同步最全的 slave，并把差异日志应用到其它 slave 上，以保障数据的一致性）；

③ 不需要修改现有的 MySQL 配置，支持 MySQL 5.0 及其以上版本；

④ 不需要增加太多的服务器；

⑤ 整体性能较好（MHA 工作在异步或半同步的主从架构上，当监控 master 时，MHA 会每隔几秒（默认 3 秒）向 master 发出ping 包，并且不需要很长的 SQL 语句用于监控 master 的健康状况。slave 需要开启 binlog，整体性能会有所降低）；

⑥ 适合任何存储引擎；

四、LVS 架构