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

5 篇文章 0 订阅

目录

一、初始 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  MangoCobarHeisenbergAltasAmoeba

数据切片

支持支持支持支持支持支持
读写分离支持支持支持支持支持支持
宕机自动切换支持不支持支持不支持半支持,影响写不支持
MySQL 协议前后端支持JDBC前端支持前后端支持前后端支持JDBC
支持的数据库MySQL、Oracle、MongoDB、postgresqlMySQLMySQLMySQLMySQLMySQL、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 架构

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值