Oracle和MySQL的高可用方案对比分析

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