热点网|医学教育网|北京pk10开奖直播 pk10开奖直播 北京赛车pk10 pk10开奖直播 北京赛车pk10 PK10开奖直播 北京赛车pk10开奖直播 北京pk10 北京pk10
你好,游客 登录
背景:
阅读新闻

数据库高可用方案PK:选择Oracle还是MySQL

[日期:2017-11-08] 来源:网络大数据  作者: [字体: ]

大数据

 

作者:杨建荣

关于Oracle和MySQL的高可用方案<,其实一直想要总结了<<,今天分为几个系列简单说说。通过这样的对比,会对两种数据库架构设计上的细节差异有一个基本的认识<。

高可用方案概览

Oracle有一套很成熟的高可用解决方案MAA。用我在OOW上的ppt来看<,这个方案自9i开始<,到今年已经有16个年头了。

 

大数据

 

当然<<,MAA方案虽好<,成本还是有的<、复杂度还是有的<,所以放眼国内的使用情况<<,RAC不一定是100%有,电信<<、证券<、寿险<<<<、银行如果用<<,基本都是全套方案<<,有些相对保守,RAC也有使用active-passive模式的<<,互联网行业如果用,清一色都是单实例和DG结合。

而MySQL因为开源的特点,官方和社区里推出了很更多的解决方案,高可用情况大体如下,仅供参考(数据引用自Percona)<。

 

大数据

 

因为时间的原因,MGR刚推出不久<,还在观察期<。MGR固然不错,MySQL Cluster方案也有PXC、Galera等方案<,个人还是更倾向于MHA。

基本情况说完了,接下来分为几个部分来解读。

Oracle RAC和MySQL MHA

先拿RAC和MHA来做一个基本的对比。

Oracle的解决方案在阿里快速发展时期支撑起了核心业务的需求。大概是这样的架构体系,看起来很庞大<。里面的RAC算是一个贵族<,用昂贵的商业存储,网络带宽要求极高<<,前端大量的小机业务还有不菲的license费用。非常典型的IOE的经典架构<。

 

大数据

 

如果要考虑异地容灾<,那么资源配置要double<<,预算翻番。

MySQL的架构方案相对来说更加平民化<,普通的PC就可以,但数量级要高<<<,做业务拆分、水平拆分就能够横向扩展出非常多的节点<<,很多大互联网公司的MySQL集群规模都是几百几百的规模,上千都不稀奇<<。如此之多的服务资源<,发生故障的概率还是有的,保证业务服务的可持续性访问是技术方案的关键。如果按照MHA的架构<<,基本上就是MHA Manager节点来负责整个集群的状态,好比一个居委会大妈<,对住户的大大小小的事情都了如指掌包打听。

 

大数据

 

当然上面的架构图过于笼统<,在MHA的高版本里面还使用了binlogServer<,我们从一些细节入手<。比如先来说说网络的事情。

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<,如下图所示:

 

大数据

 

当然网络层面不只是这些<,我们还有必要了解下TAF(Transparent Application Failover)<<。TAF是Oracle中对应用透明的故障转移<,在RAC环境中使用尤其广泛。在RAC中Load Balance这块确实做了很大的改进<,从10g版本开始的多个VIP地址的Load Balance<,到11g版本中的SCAN,做了很大的简化。

而在Failover的实现中<<,还是有一定的使用限定,比如11g中默认的SCAN-IP的实现其实默认没有Failover的选项,如果两个节点中的其中一个节点挂了<,那么原有的连接中继续查询就会提示session已经断开,需要重新连接<

(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切换的条件,从网络层面来看>,如下的红点都是潜在的隐患,有的是网络的中断>,有的是网络的延迟,发生故障时,保数据还是保性能稳定,都可以基于自己的需求来定制。从这一点上来说,丢失数据的概率是有的。绝对不是强一致性的无损复制。

 

大数据

 

把上面的图放大,其实会有更多的细节,比如ssh的连接检测和数据库的心跳检测(insert_ping)>,在整个方案里面要考虑的场景就很多了>。对于网络的切换>>>,目前MHA做的主要是保证数据复制关系,如果要深入使用>,还是要做更多的定制,比如结合Proxy的方案,使用ZooKeeper的状态检测>,使用keepalive或者VIP的网络层面的切换等。

整体来看两种方案>,RAC是集中共享>,除了存储层面的共享外,网络层面的组播其实也会提高节点间通信的成本,所以RAC对于网络的需求很大,如果存在延迟是很危险的,发生了脑裂就很尴尬了。MySQL MHA的方案是分布式的>。支持大批量的环境,节点间通信的成本相对来说要低很多。但是从数据架构的角度来说>,因为是复制的数据分布方式,所以对于存储尽管不是共享存储,对于存储的成本还是高于RAC(不是说存储的价格,是存储的数据量大小)>。

Oracle Data Guard和MySQL灾备

然后我们来继续说说灾备的部分。我就拿Oracle的DG和MySQL的方案对比。

在灾备的概念中>,Oracle DBA习惯叫做主备>,即为Primary、Standby>,而MySQL更喜欢叫做主从>,即为Master、Slave,无论怎么叫>,说得都是同一个意思。

首先在Oracle中,数据是基于物理复制(此处说的都是physical standby)>,所以对于数据库的状态和角色就很好定位,从库正常状况下是无法读写的。所以在Oracle中角色转换的概念就很清晰,failover和switchover,failover就是故障转义>,switchover就是主备切换。在MySQL中failover的概念很好理解,但是switchover相比来说,就会淡化很多>>。

Oracle因为是基于物理复制,所以一直以来备库要么就是恢复状态(recover),要么就是只读不应用状态(read_only),直到11g这个问题才解决,就是大名鼎鼎的ADG(read only with apply)。而在MySQL里面这都不是事儿>,备库可以灵活的开关read_only的参数,当然一般是不希望备库写入的,读绝对不是问题,而且还可以扩展着读,做读写分离。

对于Oracle的备库的理解>,我认为除了ADG之外,最有亮点的就是闪回数据库了,可能很多Oracle DBA都对于闪回数据库敬而远之,技术的更新很多,好端端的特性放着不用太可惜了>,比如搭建DG,分分钟DG Broker搞定,使用手工方式不见得有多高效>。

闪回的概念在MySQL里面也有,目前来说>,可以根据binlog抽取的数据做到DML的闪回>,和Oracle里面的闪回差距还很大>。Oracle里面的闪回五花八门,零零总总算下,差不多就有这些。

 

大数据

 

当然常用、实用的不见得这么多,MySQL的DML还算是原生态,可以根据binlog抽取来恢复>>,或根据第三方工具辅助>>,但DDL就是难上加难了>,目前MariaDB的DDL闪回就是一个突破,从我的理解来说,应该能够实现一部分的闪回功能,具体的效果我后面测试一下>。

所以说闪回是个大宝藏,到底有多好呢,Oracle的备库方案有了快照数据库,就是物理备库可以临时写入,带来的优点就是主库的碎片,在备库是完全一样的>。所以在SQL审核方面有着得天独厚的优势>,我在线上的很多DDL审核中都做过测试和实际应用,效果很赞>,而且11g中的闪回可以在线开在线关,所以一般10g里面我建议要慎重使用>>,11g有条件下备库端还是推荐的,满足需求就行>。当然闪回数据库不是万金油>,有个别场景是不支持的,在此就不展开了。

对于灾备来说>,数据库的切换是未雨绸缪的事情,那么到底备库切换的检查是否OK呢,Oracle里面有了DG Broker这么一个神器,还在新版本中做了很多不错的选项>,比如新版本中有了validate的选项>,可以检测主备切换的条件是否满足>。下面是DG Broker的命令中多出来的validate命令>,效果还是不错的。

 

大数据

 

此外,从高可用的角度来说>,如果在备库存在连接,做switchover时,会话会持续保持,当然会有短暂的卡顿。这也就是特色的会话保持特性。

Preserving Active Data Guard Application Connections

当然在MySQL里面就不可理解了,切换别说会话保持,卡顿的影响都微乎其微。因为Oracle基于物理复制的方式,物理一致性使得复制扩展性很难,当然也不是说完全不能实现,比如cascade standby,可以级联复制,到了12c改进一版,就是Far Sync>,号称是零数据丢失,对于跨区域的数据中心来说,会把延迟降到最低。

 

大数据

 

如果从技术架构的角度来看,部署的分布图类似下面的形式,中间有远距离的数据传输,可以通过中间的节点来转换,中间这个节点很特别>,是不存数据的,只是保持一个内存结构>,同步数据>。

 

大数据

 

还有就是延迟,我测试过DG的延迟,和MySQL在基本相似的压力情况下,Oracle基本上控制在0.1秒左右,MySQL的复制就会有一些延迟的放大。

所以总体看下来,Oracle的方案是一种很专业的解决方案>,工具全,架构相对复杂,数据同步是强一致性。所以在涉及交易的业务中对它更加偏爱。

再来看看MySQL方向的改进。我们不比单机性能和延迟了,因为这个确实是有差距,而且硬拼也没有太大的意义>,我们从整体架构角度来考虑>>,这些又是Oracle难以实现的地方。

首先说下主从复制,MySQL是典型的逻辑复制,主库端可以承载大批量的并发,但是性能瓶颈很明显,主库的并发最后落到文件上还是串行的,抛开日志传输进程的开销,最大的瓶颈就在于SQL_Thread的应用延迟>。就好比中午大家出去吃饭>>,前台可以并发点很多的菜品>,但后台的厨师就好比是SQL_Thread,他得一道菜一道菜做啊。怎么能做得更快呢?比如你叫了5分盖饭>,他可以一次性炒出来,这样就能够大大提高效率,所以前台的小姑娘也会建议你和其他人点一样的菜>,原因就一个字——快。这用在并行复制上就是类似的道理。MySQL 5.6没法做到细粒度的并行复制,只能在库级别>>,而在MySQL 5.7中可以做到表级别更细粒度的,这个改进就很明显了。

 

大数据

 

所以延迟的问题能够解决,后续的扩展就容易多了>,MySQL的扩展甚至可以做到指数级的扩展方式,如果允许一些低延时,大量的读请求就可以逐步分解>。所以一主多从的架构方式也是见怪不怪。

值得一提的是MHA的一主多从架构中,如果多个从库存在延迟,在切换的时候MHA会补齐差异的日志,这是MHA的一大亮点。

而MySQL的级联复制就更纯粹了,和Oracle相比的最大优势就是一个数据库可以既是主库也可以同时是从库,起到承上启下的作用。

 

大数据

 

这种扩展方式简直是酸爽,在一些跨数据中心的场景,允许一定延迟的情况下还是有用武之地>。比如你需要从北美读数据,可以从北美推送数据库到香港或者新加坡,再推送到北京。有了这种方式就很容易扩展。当然在实时交易中还是存在一些瓶颈和缺陷。

展望和后续补充

如果抛开具体的数据库>,整体来说数据量和业务量到达一定程度都会碰到一系列的问题>。这些都是痛点也是难点,常见的问题如下:

单台服务器无法承载已有的压力
数据库单表容量越来越大
大量的读写需求无法平衡
资源如果扩容,应用改动较大
资源的负载没法拆分,或者不易拆分

这时就需要扩展,就需要匹配的解决方案,比如中间件的方案,有的解决了一些通用的问题>,有些侧重于某一方面。比如需要考虑sharding来分片>>,读写分离来做分担读写压力>,前端海量访问可以通过大量的水平扩展来分担。

从这个角度来说,MySQL是以架构和规模取胜,通过业务拆分和架构拆分能够实现线性扩展>>。而Oracle的扩展性虽然没有那么好,但从架构和业务层面来说也能做,这个后续有机会再细细说一说,可以拟一篇分布式方面的文章>。

小结

简单总结一下,高可用的方案选择很多,各家有各家的需求>,能定制的定制>,能开源的开源。大道至简,只要满足了需求>>,系统稳定不背锅,那就是最好的方案。





收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款
  • 陈志朋《Patience》欣赏版MV首发 造型再创新潮陈志朋 2018-05-20
  • 纽约前市长:华府谎言当道,将威胁美国民主制度 2018-05-20
  • 孩子将来不孝顺的4个信号,第三种必须立即纠正! 2018-05-20
  • 王国平:杭州明确重点发展八大门类文化创意产业 2018-05-19
  • 失眠和心理病是难兄难弟 2018-05-19
  • 紫光阁中共中央国家机关工作委员会 2018-05-19
  • 吉利博越优惠达0.2万 数量有限颜色可选 2018-05-18
  • 历害!禅师用简单一招让他祛除病魔 2018-05-18
  • NATUZZI 2018和谐共生的艺术之家合作项目正式启动 2018-05-17
  • 人气更高!济南正从门票经济向旅游产业经济转型 2018-05-17
  • 互联网论坛社区服务管理规定 2018-05-16
  • 2013博鳌亚洲论坛嘉宾精彩演讲 2018-05-16
  • 发现使用专利字体 南京一侵权方修改后公证 2018-05-16
  • 不对称耳环已经不再新鲜 那什么最时髦呢? 2018-05-15
  • 锡马专刊 PB衫、破三奖杯、纪录片,锡马五年,我们不说再见! 2018-05-15
  • 阿启网 | 男士时尚 | 冠珠陶瓷 | 网站运营 | 系统盒 | 重庆周边旅游景点大全 | 海南房产 | 现金炸金花 | 快递单号网点查询 | 网贷tansend | 微信群 | 冠珠陶瓷 | 创业者 | 在线教程 |