中国领先的IT技术网站
|
|

Oracle和MySQL的高可用方案对比(一)

关于Oracle和MySQL的高可用方案,其实一直想要总结了,就会分为几个系列来简单说说。通过这样的对比,会对两种数据库架构设计上的细节差异有一个基本的认识。Oracle有一套很成熟的解决方案。用我在OOW上的ppt来看,是MAA的方案,今年是这个方案的16周年了。

作者:杨建荣来源:杨建荣的学习笔记|2017-11-03 10:08

Tech Neo技术沙龙 | 11月25号,九州云/ZStack与您一起探讨云时代网络边界管理实践


关于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(不是说存储的价格,是存储的数据量大小).

【编辑推荐】

  1. 如何配置MySQL数据库超时设置
  2. 7大绝招帮你轻轻松松提升MySQL性能
  3. 带您深入了解MySQL的权限管理
  4. MySQL 8.0备受瞩目的新特性大放送!
  5. MySQL高可用方案MHA的一些总结和思考
【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

PHP5与MySQL5 Web开发技术详解

本书是目前中文版本第一个真正介绍PHP 5及MySQL 5新增语法与功能的权威宝典! 本书本着精、全、要三宗旨,从理论中延伸,从实践中深入,详...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
× CTO训练营(深圳站)