简单对比Oracle和MySQL的高可用方案-创新互联
下面讲讲关于简单对比Oracle和MySQL的高可用方案,文字的奥妙在于贴近主题相关。所以,闲话就不谈了,我们直接看下文吧,相信看完简单对比Oracle和MySQL的高可用方案这篇文章你一定会有所受益。
成都创新互联公司主营叶城网站建设的网络公司,主营网站建设方案,成都APP应用开发,叶城h5小程序设计搭建,叶城网站营销推广欢迎叶城等地区企业咨询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(不是说存储的价格,是存储的数据量大小).
对于以上简单对比Oracle和MySQL的高可用方案相关内容,大家还有什么不明白的地方吗?或者想要了解更多相关,可以继续关注我们的行业资讯板块。
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
当前名称:简单对比Oracle和MySQL的高可用方案-创新互联
文章出自:http://pwwzsj.com/article/copgph.html