RAC 11.2 体系结构（二）

 Failover的相关讨论

 

       当设计一个机遇RAC的应用的时候，开发人员和设计人员需要面对一个事实就是：即使是最好的硬件也不是100%可靠的。使用RAC可以降低实例故障带来的影响，但在应用端上需要做一些额外的措施来屏蔽故障对应用带来的影响。

       但是，并不是所有的应用都支持RAC。商业的、现成的包常常不支持RAC。在这些情况下，一个active/passive集群或RAC One Node系统是一个合适的替代方案。

       供应商提供的支持RAC的应用或内部开发的应用可以使用不同的高可用技术来屏蔽实例故障。这些技术包括TAF(Transparent Application Failover)和FCF(Fst Connection Failover)。

       应用经常是在单实例Oracle中开发的，这不是一个问题，因为应用照样可以工作在RAC中。但把failover支持添加到内部开发或源代码可用的应用中汇更加容易。当设计一个新的应用时，故障切换应该一开始就要考虑，因为重新设计再引入这个特征的成本可能会很大。

 

透明应用切换(TAF)

 

       TAF允许数据库连接在一个节点发生故障时，使用OCI库来故障切换到另一个存活的节点中。使用JDBC thin driver的应用不能从这个特性中得到好处，因为该驱动不使用OCI。TAF是一个客户端的特性：当发生节点故障时，将发送一个通知给客户端上的触发动作。

 

切换模式

 

       TAF可以配置在两个模式下工作，或者可以禁用。如果把失效也算作一个模式的话，TAF可以有下面三个选项：Session failover、Select failover、None(默认)。

       session failover模式可能是最常见的情况，因为它不需要任何代码上的变动来实现。所有需要做的就是在tnsnames.ora文件中配置一个适当的本地命名定义或将TAF策略关联到数据库服务中。TAF会在一个节点发生故障时自动使用相同的连接串来重新连接用户会话。

       select failover模式允许客户端在连接重新建立后从打开的游标中集训获取记录。本质上，TAF会重新执行相同的查询，然后丢弃已经返回给用户的那部分记录，来实现故障切换的透明。会有一些轻微的开销，因为Oracle需要对已经传输的数据进行追踪。

       如果你显式指定了none作为failover类型，不会做任何故障切换。指定none而不是省略FAILOVER_MODE参数的唯一理由，就是要显式地禁用TAF。

       故障发生时任何执行DML而发生的改变都不能通过TAF来恢复，在这种情况下，未提交的事务在会话重建后将被回滚。

       除了节点故障以外，TAF还能与Data Guard、active/passive集群一起配置，在Data Guard环境中能提供一个故障切换能力。

 

Failover Methods

 

       指定了failover mode后，用户可以进一步定义一个方法来确切地指定TAF如何重建在其他实例上的连接。failover method可以在failover type外单独定义，failover method决定failover如何工作，可用的选项有：Basic、Preconnect。

       和名称一样，basic选项让客户端只有在节点故障以后才会重建一个新的连接。这可能会导致存活的节点上会收到大量新的连接请求。在双节点RAC的情况下，在所有用户连接都重建完以前，可能会导致性能问题。如果你准备使用这种方法，应该在设计阶段就对可能的性能问题进行测试。

       preconnect选项配置要稍微更麻烦一些。当你指定了preconnect参数，客户端将在备份实例上预连接一个会话来加速会话的切换。你要记住这些预建立的连接会增加集群的会话数量。另外，你需要定义这些备份连接。

 

快速连接切换(FCF)和快速应用通知(FAN)

       快速连接切换为支持FAN的客户端提供了从实例故障中恢复的方法。FAN是为集群重配置提供UP和DOWN事件的一个框架，这些事件可以应用在数据库服务和实例的可用性中。

       下列客户端可以支持FCF:

• • Java数据库连接驱动(JDBC)
  • Oracle Universal Connection Pool(UCP)
  • 使用OCI的客户端
  • Oracle Data Providers for .Net

       使用FAN最贱当的方法就是用上面的客户端，此时不需要对应用做代码上的修改，因为这些客户端已经集成了对FAN事件的支持。除了节点故障的保护外，集群FAN和FCF的应用还使用Oracle 10.2引入的负载均衡顾问来最好地利用集群中的资源。

       使用FAN的一个很大的优势在于它的设计。不用要求应用去查看数据库来获得信息，通知框架(the notification framework)会向应用告知集群的变化。这种方式更不容易将应用连接到挂起或超负荷的节点上，或是使用一个指向故障实例的不正常的连接。

       数据库服务需要经过定义来使用FAN。在RAC中，数据库服务是工作量管理的主要工具。它允许用户将类似的工作量聚在一起，或者将集群拆分成几个单元。服务总是和数据库实例联系在一起，它们还能使用特定的属性来启用高可用技术，比如TAF和FAN。

       FCF建立在高可用框架上，支持FAN事件的客户端通过接收的事件来进行处理。具体地说，FAN和FCF依赖于ONS后台进程发布的事件，这个进程会自动安装，并配置为RAC节点应用的一部分。JDBC连接池是使用这些事件的客户端中的一个。当接收到框架发出的DOWN事件，池中与故障实例或服务相关的连接会被标记为不可用，并被清除。为了弥补这些减少的会话，会有新的会话在集群的其他节点中创建，就像服务中定义的那样。使用FCF的先决条件很简单，独立的Java应用或连接池就可以满足。

       从Oracle 11.1.0.7开始，原来FCF需要用到的隐式连接缓存就被弃用了。和大多数Oracle特性一样，它在下一个版本中不会消失，但你最终会看到它被移除。名为Nniversal Connection Pool(UCP)的新特性取代了隐式连接缓存的功能。

       如果指定了db_domain初始化参数，在11.2的初始版本中FCF可能会不可用。这是由于一个未发布的bug:"8779597 - [11GR2-LNX-090731]A NUMBER OF JDBC CONNECTION IS INCORRECT WITH FAN UP EVENT" 有个一次性补丁可以使用，这个bug在11.2.0.2中会被修正。

       有趣的是，FCF并不局限于集群中发布的事件。Data Guard broker也可以在failover操作后发布FAN事件。甚至在单实例Oracle中，如果在Oracle Restart中注册，也可以接收到事件。正确配置你的关于主备数据库的连接串，可以在Data Guard角色转换后进行会话failover，非常高效和简单。