Near Continuous Availability of Network Attached Relational Database Systems
Original Publication Date: 2002-Oct-29
Included in the Prior Art Database: 2003-Jun-19
Near Continuous Availability Relational Database System Disclosed is a system configuration providing for near continuous availability of a relational database to provide high volume, 24 hour per day, 7 day per week operations support of critical applications such as sales over the Internet. The system utilizes multiple Intel processor-based or UNIX servers with commercially available software to achieve the Near Continuous Availability of the system. This is difficult to obtain because typically relational databases require periodic maintenance for backups and other system activities which frequently result in some hours of down time per week. Complicating the problem is the fact that high availability platforms address recovery, during failure scenarios, to the operating system level and do not aid relational database recoveries, which generally last at least 20 minutes or more. For critical applications that use relational databases, such downtimes may have a severe impact (such as lost sales). The configuration uses one or more "front end" dispatcher computers to route requests for Relational Database Management System (RDBMS) service to either the primary or secondary RDBMS server as appropriate. When in normal operations, the primary and secondary RDBMS servers maintain duplicate databases and transmit updates between the two on a near continuous basis. For normal RDBMS maintenance, the secondary server can be worked on independently while the primary server continues to support operations. Upon completion of the maintenance activities, the secondary server will update the primary server as necessary, then take over as the primary server while the original primary server becomes the secondary and is then used for RDBMS maintenance. In a failure scenario, the front end dispatcher will detect failed communications with the primary server and then send subsequent requests for RDBMS service to the secondary server. The RDBMS service will appear to be continuously available to the requester, though one failed communication attempt may be detected (the communication should be successful on retry). The system was verified in a lab environment in February, 2000. The lab environment utilized UNIX servers, DB2® RDBMS, DB2® DataPropagator , and ®IBM WebSphere Network Dispatcher. Figure 1 below represents the configuration used for verification. The request for RDBMS service is directed to the Network Dispatcher (ND). The ND directs the request to the appropriate RDBMS which services the client request. DB2 DataPropagator (DPropR) is used to keep the primary and secondary RDBMS servers synchronized. Primary and secondary RDBMS server content is managed or updated from a staging server via DPropR or some other DB2 utility.