,,,,,,,,,,,,,,,,,,,,,,,,,,,,
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=(描述=(地址=(协议(TCP)(主机=192.168.3.101)(端口=1521)) (地址=(协议(TCP)(主机=192.168.3.201)(端口=1521)) (LOAD_BALANCE=是的) (故障转移=alt="简单对比甲骨文和MySQL的高可用方案">简单对比甲骨文和MySQL的高可用方案
