Database Reference
In-Depth Information
Fast Connection Failover
Fast Connection Failover (FCF) is a proactive failover method to avoid downtime when there is an instance failure.
Proactive connection management improves application availability and user experience, as you can reduce runtime
errors. Here are a few examples where FCF can be used to avoid errors:
•
After a database instance failure, all connections in a connection pool must be recycled by
the connection manager. Usually, stale connections are identified only when the connection
is reused by the application
4
, but the failure is detected only after an error is encountered by
the application. This late detection of error condition can lead to application errors and other
undesirable user experiences.
•
Connection pool connections that were busy in the database executing queries might need to
wait for TCP timeouts. This delay can lead to slowness and errors in the application.
•
After the recovery of failed instances, the application might not reconnect to the recovered
node. This issue can lead to unnecessary overload of the surviving nodes.
Instance failures can be propagated earlier to the application, and errors can be minimized by requesting the
application to recycle its connections after node or service failures. Essentially, service changes, node failures, node
up/down events, etc., are communicated immediately to the application, and this propagation is known as FAN. After
receiving a FAN event, the application proactively recycles connections or takes corrective actions depending upon
the nature of the failure.
FCF is a technique that captures FAN events and reacts to the received FAN events. FAN events can be captured
and connections recycled utilizing a few technologies:
1.
Your application can implement connection pool technology that handles the FAN events,
such as Oracle WebLogic Active GridLink data source, Oracle JDBC Universal Connection
Pool, ODP.Net connection pool, OCI session pools, etc.
2.
Your application can use programmatic interfaces to capture FAN events and react
accordingly.
3.
Or, you can use database side callouts to handle FAN events.
WebLogic Active GridLink
WebLogic Active GridLink for RAC is a data source available in Oracle WebLogic version 11g. This data source is
integrated with RAC to handle FAN events and LBA without the help of any code changes. To make use of Active
GridLink for FCF, you should configure an Active GridLink data source to connect to the SCAN listener and the ONS
daemon, in a WebLogic configuration screen.
The ONS daemon propagates RAC topology changes to the registered clients. Any topology change is propagated
to the clients listening to the SCAN IP address and 6200 ports. GridLink data source registers to the ONS daemon to
receive notifications. If there are any topology changes as broadcast by the ONS daemon, such as instance restart,
then GridLink data source captures the events and recycles the connections in the connection pool. Further, if there is
an Instance UP event due to instance restart, then that event is captured by GridLink data source, and the connections
are reapportioned among available nodes. This connection management avoids overloading of too few nodes after
node recovery. Also, Active GridLink receives LBAs from ONS daemons, and GridLink data source uses connections
from the least-loaded instances, implementing the runtime load balancing algorithm.
4
Applications typically borrow connections from a connection pool, perform database activity, and return the connections to the connection
pool. It is more likely that some connections may not have been reused for days, and so there may be application errors after few days.
