RAC 11.2 architecture (II)

Failover Discussion

 

When designing an application with the opportunity RAC, developers and designers need to face the fact that even the best hardware is not 100% reliable. Using RAC can reduce the impact of instance faults, but some additional measures are required on the application end to shield the impact of faults on the application.

However, not all applications support RAC. Commercial and ready-made packages often do not support RAC. In these cases, an active/passive cluster or RAC one node system is an appropriate alternative.

Applications provided by the supplier that support RAC or internally developed applications can use different high-availability technologies to shield instance faults. These technologies include TAF (transparent application failover) and FCF (Fst connection failover ).

Applications are often developed in a single instance of Oracle, which is not a problem because applications can still work in RAC. However, it is easier to add Failover Support to internal development or applications with available source code. When designing a new application, Failover should be taken into consideration at the beginning, because the cost of re-designing and introducing this feature may be high.

 

Transparent application switching (TAF)

 

TAF allows the database to fail over to another active node when a node fails. Applications using JDBC thin driver cannot benefit from this feature because the driver does not use OCI. TAF is a client feature: When a node failure occurs, a notification is sent to the client for triggering.

 

Switch Mode

 

TAF can be configured to work in two modes or disabled. TAF can have the following three options: Session failover, select failover, and none (default ).

The session failover mode may be the most common situation because it does not require any code changes. All you need to do is configure an appropriate local naming definition in the tnsnames. ora file or associate the TAF policy to the database service. When a node fails, TAF automatically uses the same connection string to reconnect to the user session.

Select failover mode allows the client to retrieve records from the open cursor after the connection is re-established. Essentially, TAF re-executes the same query and then discards the records that have been returned to the user to implement transparent failover. There will be some minor overhead, because Oracle needs to track the transmitted data.

If you explicitly specify none as the Failover type, no failover will be performed. The only reason for specifying none instead of omitting the failover_mode parameter is to explicitly disable TAF.

When a fault occurs, any changes that occur when DML is executed cannot be recovered through TAF. In this case, uncommitted transactions will be rolled back after session reconstruction.

In addition to node faults, TAF can be configured with data guard and active/passive clusters to provide failover capabilities in the Data guard environment.

 

Failover Methods

 

After failover mode is specified, You can further define a method to specify exactly how TAF reconstructs connections on other instances. Failover method can be defined separately outside the Failover type. Failover method determines how failover works. Available options include basic and preconnect.

Like the name, the basic option allows the client to rebuild a new connection only after the node fails. This may cause a large number of new connection requests to the surviving node. In the case of dual-node RAC, performance problems may occur before all user connections are rebuilt. If you are going to use this method, you should test possible performance problems during the design phase.

Preconnect option configuration is a little more troublesome. When you specify the preconnect parameter, the client will pre-connect a session on the backup instance to accelerate session switching. Remember that these pre-established connections will increase the number of sessions in the cluster. In addition, you need to define these backup connections.

 

Quick connection switching (FCF) and Quick Application Notification (fan) provides a method to recover a fan client from instance failure. Fan is a framework that provides up and down events for cluster reconfiguration. These events can be applied to database services and instance availability. The following clients support FCF:

• Java database connection Driver (JDBC)
• Oracle universal connection pool (UCP)
• Use OCI Client
• Oracle data providers for. net

The best way to use fan is to use the above client. You do not need to modify the application code because these clients have integrated support for fan events. In addition to node Failure Protection, cluster fan and FCF applications also use Server Load balancer consultants introduced by Oracle 10.2 to make the best use of cluster resources. A major advantage of using fan is its design. The application is not required to view the database to obtain information. The notification framework informs the application of the cluster changes. This method makes it easier to connect an application to a suspended or overloaded node, or use an abnormal connection pointing to a faulty instance. The database service must be defined to use the fan. In RAC, Database Service is the main tool for workload management. It allows users to combine similar workloads or split a cluster into several units. Services are always associated with database instances. They can also use specific attributes to enable high-availability technologies, such as TAF and fan. FCF is built on a high-availability framework and supports the processing of events received by the fan event client. Specifically, Fan and FCF depend on events released by the ONS background process. This process is automatically installed and configured as part of the RAC node application. The JDBC connection pool is one of the clients that use these events. When a down event is received by the framework, connections related to faulty instances or services in the pool are marked as unavailable and cleared. To make up for these reduced sessions, new sessions will be created in other nodes of the cluster, as defined in the service. The prerequisites for using FCF are simple, and independent Java applications or connection pools can be met. From Oracle 11.1.0.7, the implicit connection cache used by FCF is discarded. Like most Oracle features, it will not disappear in the next version, but you will eventually see it removed. The new feature named nniversal connection pool (UCP) replaces the implicit connection cache function. If the db_domain initialization parameter is specified, FCF may be unavailable in the initial version 11.2. This is because of an unpublished BUG: "8779597-[11gr2-lnx-090731] A number of JDBC connection is incorrect with fan up event" A one-time patch can be used, this bug is fixed in 11.2.0.2. Interestingly, FCF is not limited to events released in clusters. Data guard broker can also publish a fan event after the failover operation. Even in a single instance of Oracle, If you register in Oracle restart, you can also receive events. Correctly configure your connection string for the master and slave databases. You can perform session failover after data guard role conversion, which is very efficient and simple.