MySQL 是一个开放源码的小型关联式数据库管理系统, 开发者为瑞典 MySQL AB 公司 MySQL 被广泛地应用在 Internet 上的中小型网站中由于其体积小速度快总体拥有成本低, 尤其是开放源码这一特点, 许多中小型网站为了降低网站总体拥有成本而选择了 MySQL 作为网站数据库
这篇文章主要介绍了 Oracle 和 MySQL 的高可用方案对比分析, 非常不错, 具有参考借鉴价值, 需要的朋友可以参考下
关于 Oracle 和 MySQL 的高可用方案, 其实一直想要总结了, 就会分为几个系列来简单说说通过这样的对比, 会对两种数据库架构设计上的细节差异有一个基本的认识 Oracle 有一套很成熟的解决方案用我在 OOW 上的 ppt 来看, 是 MAA 的方案, 今年是这个方案的 16 周年了
而 MySQL 因为开源的特点, 社区里推出了更多的解决方案, 个人的见解, InnoDB Cluster 会是 MySQL 以后的高可用方案标配
而目前来看, MGR 固然不错, MySQL Cluster 方案也有, PXC,Galera 等方案, 个人还是更倾向于 MHA.
所以本文会分为几个部分来解读, 先拿 RAC 和 MHA 来做一个基本的对比
Oracle 的解决方案在阿里快速发展时期支撑起了核心业务的需求大概是这样的架构体系, 看起来很庞大里面的 RAC 算是一个贵族, 用昂贵的商业存储, 网络带宽要求极高, 前端大量的小机业务还有不菲的 licence 费用非常典型的 IOE 的经典架构
如果要考虑异地容灾, 那么资源配置要 double, 预算翻番
MySQL 的架构方案相对来说更加平民化, 普通的 pc 就可以, 但是数量级要高, 做业务拆分, 水平拆分就能够横向扩展出非常多的节点, 很多大互联网公司的 MySQL 集群规模都是几百几百的规模, 上千都不稀奇如此之多的服务资源, 发生故障的概率还是有的, 保证业务服务的可持续性访问, 是技术方案的关键如果按照 MHA 的架构, 基本上就是 MHA Manager 节点来负责整个集群的状态, 好比一个居委会大妈, 对住户的大大小小的事情都了如指掌包打听
当然上面的说法过于笼统, 我们从一些细节入手比如先来说说网络的事情
Oracle 对于网络的要求还是很严格的, 一般都是要 2 块物理网卡, 每台服务器需要至少 3 个 IP, Public IP,private IP,VIP, 除了共享存储, 至少需要 2 个计算节点
private IP 是节点间互信的, Public IP 和 VIP 在一个网段, 简单来说, VIP 是对外的, 是 public IP 所在网络的漂移 IP, 在 10g 里面都是通过 VIP 来做负载均衡的, 11g 开始有了 scan-IP, 原来的 VIP 还是保留, 所以 Oracle 里面的网络配置要求还是很高的抛开共享存储, 搭建的核心就是网络配置了, 网络通则通
scan-IP 还可以继续扩展, 最多支持 3 个 scan-ip, 如下图所示
当然网络层面不只是这些, 这方面的亮点 Oracle 就很专业了我们有必要了解下 TAF, 在我的书中 Oracle DBA 工作笔记中, 我这样写道:
TAF(Transparent Application Failover) 是 Oracle 中对应用透明的故障转移, 在 RAC 环境中使用尤其广泛在 RAC 中 Load Balance 这块确实做了很大的改进, 从 10g 版本开始的多个 VIP 地址的 Load Balance, 到 11g 版本中的 SCAN, 做了很大的简化
而在 Failover 的实现中, 还是有一定的使用限定, 比如 11g 中默认的 SCAN-IP 的实现其实默认没有 Failover 的选项, 如果两个节点中的其中一个节点挂了, 那么原有的连接中继续查询就会提示 session 已经断开, 需要重新连接客户端 TAF 主要会讨论 Failover Method 和 Failover Type 的一些简单内容
(1)Failover Method
Failover Method 的主要思路就是换取故障转移时间, 或者换取资源来实现
可以这样来理解, 假设我们存在两个节点, 如果某个 session 连接到了节点 2, 然而节点 2 突然挂了, 为了更快处理 Failover 这种情况, Failover Method 有 preconnect 和 basic 两种
preconnect 这种预连接方式还是会占用较多的资源使用, 在各个节点上会预先占用一部分额外的资源, 在切换时会相对更加平滑, 速度更快
basic 这种方式, 则在发生 Failover 时, 再去切换对应的资源, 中间会有一些卡顿, 但是对于资源的消耗相对来说要小很多
简单来说, basic 方式会在故障发生时才去判断, 而 preconnect 则是未雨绸缪; 从实际的应用来说, basic 这种方式更加通用, 也是默认的故障转移方式
(2)Failover Type
Failover Type 实现更加丰富而且灵活, 非常强大这个时候控制粒度可以针对用户 SQL 的执行情况进行控制, 有 select 和 session 两种; 通过一个小例子说明一下
比如, 我们有个很大的查询在节点 2 上进行, 结果节点 2 突然挂了, 对于正在执行的查询, 比如说有 10 000 条数据, 结果刚好故障发生的时候查出了 8 000 条, 那么剩下的 2 000 该怎么处理
第一种方式就是使用 select; 即会完成故障切换, 继续把剩下的 2 000 条记录返回, 当然中间会有一些上下文环境的切换, 对于用户是透明的
第二种方式是 session; 即直接断开连接, 要求重新查询
在 10g 版本中借助于 VIP 的配置达到 Load Balance+Failover 的配置如下:
- racdb=
- (DESCRIPTION =
- (ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.101)(PORT= 1521))
- (ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.201)(PORT= 1521))
- (LOAD_BALANCE = yes)
- (FAILOVER = ON)
- (CONNECT_DATA =
- (SERVER= DEDICATED)
- (SERVICE_NAME = racdb)
- (FAILOVER_MODE =
- (TYPE= SELECT)
- (METHOD= BASIC)
- (RETRIES = 30)
- (DELAY = 5))))
如果 11g 的 SCAN-IP 也想进一步扩展 Failover, 同样也需要设置 failover_mode 和对应的类型
- RACDB =
- (DESCRIPTION =
- (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
- (CONNECT_DATA =
- (SERVER = DEDICATED)
- (SERVICE_NAME = RACDB)
- )
- )
从这个角度来看 Oracle 的方案真是精细再来看看 MySQL 的方案
分布式的方案, 让 MySQL 看起来像一把瑞士牛刀, 对于网络层面的要求, 几乎可以说 MySQL 没有什么要求, 申请一主一从, 那么就只需要 4 个 IP 即可 (主, 从, VIP,MHA_Manager(考虑一个 manager 节点)), 一主两从是 5 个
这一点上 MySQL 原生并不支持所谓的负载均衡, 可以通过前端的业务来分流, 比如使用中间件 proxy, 或者持续的拆分, 达到一定的粒度后, 通过架构设计的方式来满足需求因为基于逻辑的复制, 很容易扩展, 一主多从都是很常见的, 代价也不高, 延迟不能说没有, 只是很低, 能够适应绝大部分的互联网业务需求
而说到触发 MHA 切换的条件, 从网络层面来看, 如下的红点都是潜在的隐患, 有的是网络的中断, 有的是网络的延迟, 发生故障的时候, 保数据还是保性能稳定, 都可以基于自己的需求来定制从这一点上来说, 丢失数据的概率是有的绝对不是强一致性的无损复制
整体来看两种方案, RAC 是集中共享, 除了存储层面的共享外, 网络层面的组播其实也会提高节点间通信的成本, 所以 RAC 对于网络的需求很大, 如果存在延迟是很危险的, 发生了脑裂就很尴尬了 MySQL MHA 的方案是分布式的支持大批量的环境, 节点间通信的成本相对来说要低很多但是从数据架构的角度来说, 因为是复制的数据分布方式, 所以对于存储尽管不是共享存储, 但是对于存储的成本还是高于 RAC(不是说存储的价格, 是存储的数据量大小).
来源: http://www.phperz.com/article/18/0216/360728.html