转载

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

对比

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

昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。

今天来说下Oracle的DG和MySQL的方案对比,相比来说,可能这方面MySQL会单薄一些,所以文末会说下InnoDB Cluster。

在灾备的概念中,Oracle DBA喜欢叫做主备,即为Primary,Standby,而MySQL喜欢叫做主从,即为Master,Slave

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

Oracle因为是基于物理复制,所以一直以来备库要么就是恢复状态,要么就是只读不应用状态,直到11g这个问题才解决,就是大名鼎鼎的ADG,而在MySQL里面这都不是事儿,备库可以灵活的开关read_only的参数,当然一般是不希望备库写入的。

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

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

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

当然常用,实用的不见得这么多,MySQL的DML还算是原生态,但是DDL就是难上加难了,目前MariaDB的DDL闪回就是一个突破,从我的理解来说,应该能够实现一部分的闪回功能,具体的效果我后面测试一下。

所以说闪回是个大宝藏,到底有多好呢,Oracle的备库方案有了快照数据库,就是物理备库可以临时写入,带来的优点就是主库的碎片,在备库是完全一样的。所以在SQL审核方面有着得天独厚的优势,我在线上的很多DDL审核中都做过测试和实际应用,效果很赞。

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

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

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

Preserving Active Data Guard Application Connections

当然在MySQL里面就不可理解了,切换别说会话保持,卡顿的影响都微乎其微。

基于物理复制的方式,Oracle的复制扩展性就很难实现,当然也不是说完全不能实现,比如cascade standby,可以级联复制,到了12c改进一版,就是Far Sync,号称是零数据丢失,对于跨区域的数据中心来说,会把延迟降到最低。

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

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

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

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

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

我们再来看看MySQL方向的改进。我们不比单机性能和延迟了,因为这个确实是有差距,我们比其他的方面,刚好又是Oracle难以实现的地方。

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

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

所以延迟的问题能够解决,后续的扩展就容易多了,MySQL的扩展甚至可以做到指数级的扩展方式,如果允许一些第延时,那么大量的读请求就可以逐步分解。所以一主多从的架构方式也是见怪不怪。而且在MHA中,如果多个从库存在延迟,在切换的时候MHA会补上差异的日志,这是MHA的一大亮点。

而MySQL的级联复制就很纯粹了,和Oracle相比的最大优势就是一个数据库可以既是主库也可以同时是从库,起到承上启下的作用。这种扩展方式兼职是酸爽,在一些跨数据中心的场景,允许一定延迟的情况下还是有用武之地。比如你从北美读数据,可以经过北京的几点达到香港或者新加坡,连接到北美。

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

有了这种方式就很容易扩展。当然在实时交易中还是存在一些瓶颈和缺陷。MySQL的扩展性方案很多,很多时候都会需要考虑中间件的方案,需要考虑sharding来分片,读写分离来做分担读写压力,前端访问可以通过大量的水平扩展来做,从这个角度来说,MySQL是以规模取胜,因为不是一个人在战斗。

比如在MySQL 5.7.17中一直诟病没有的官方高可用方案MGR正式推出了。这对社区是一个很好的信号,然后紧锣密鼓有了InnoDB Cluster,虽然还没有实现sharding,但是容灾切换,读写分离是有了。由此也能看到MySQL其实不只是想做一个方案,而是希望做到更多的集成。

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

正文到此结束
Loading...