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

02-08 12:30