目录
一、初始 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 架构