Systems and methods for providing client connection fail-over

• US 7,606,839 B2
• Filed: 05/29/2007
• Issued: 10/20/2009
• Est. Priority Date: 02/06/2001
• Status: Expired due to Term

• Current Assignee: Quest Software, Inc.
• Original Assignee: Quest Software, Inc.
• Inventors: Kalderon, Eyal, Romine, William J., Aronoff, Eyal
• Primary Examiner(s): LEWIS, CHERYL RENEA
• Application Number:
  US11/754,891
• Publication Number:
  US 20070226220A1
• Time in Patent Office: 875 Days
• Field of Search: 707/10, 707/200, 707/201
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1443 Transmit or communication errors
• CPC Class Codes: G06F 11/2025 using centralised failover control functionality
• CPC Class Codes: G06F 11/203 using migration
• CPC Class Codes: G06F 11/2038 with a single idle spare processing component
• CPC Class Codes: G06F 11/2046 where the redundant components share persistent storage G06F11/2043 takes precedence
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/10015 Access to distributed or replicated servers, e.g. using brokers
• CPC Class Codes: H04L 67/1029 using data related to the state of servers by a load balancer
• CPC Class Codes: H04L 67/1034 Reaction to server failures by a load balancer
• CPC Class Codes: H04L 67/1095 Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
• CPC Class Codes: H04L 69/40 for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection management of faults, events, alarms or notifications in data switching networks H04L41/06
• CPC Class Codes: H04L 9/40 Network security protocols
• CPC Class Codes: Y10S 707/99931 Database or file accessing
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users

Abstract

Aspects of embodiments of the present disclosure include a highly available database cluster employing replication between two or more data files. The cluster also can maintain a connection with potentially geographically remote client application programs, including non-fault tolerant application programs, even in the event of one of the database management systems (DBMS) of the cluster becoming unavailable.

Claims

1. A database cluster for providing client connection fail-over, the database cluster comprising:

a first computing system comprising;

a first management module configured to form a client connection with and receive at least one transaction from a client, and

a first database management system (DBMS) in communication with the first management module to receive and execute the at least one transaction on data stored in one or more data files;

a replication module configured to record replication data indicating changes made to the data stored in the one or more data files based on the at least one transaction; and

a second computing system in communication with the replication module, the second computing system comprising;

a second management module configured to receive a copy of the at least one transaction from the first computing system, the second management module being further configured to purge at least one of (i) the copy of the at least one transaction and (ii) the replication data when the copy of the at least one transaction is redundant to the replication data,

wherein the second management module is configured to monitor a performance of the first computing system and the first management module is configured to monitor a performance of the second computing system,

and wherein when the second management module determines that an unbalanced workload exists between the first and the second computing systems, the second management module transparently assumes the client connection and begins to receive additional transactions from the client to be executed against the one or more data files.

2. The database cluster of claim 1, further comprising a second DBMS in communication with the second management module, the second DBMS being configured to access data stored in the one or more data files.

3. The database cluster of claim 1, wherein the first management module and the second management module exchange statistics usable by the second management module to monitor the performance of the first computing system.

4. The database cluster of claim 3, wherein the statistics include a number of clients connected to the first management module.

5. The database cluster of claim 1, wherein the client connection comprises a Transmission Control Protocol/Internet Protocol (TCP/IP) connection.

6. The database cluster of claim 1, wherein the unbalanced workload comprises a failure of the first DBMS.

7. The database cluster of claim 1, wherein each of the at least one transaction and the replication data is associated with a timestamp.

8. The database cluster of claim 7, wherein the second management module is configured to determine if the at least one transaction is redundant to the copy of the replication data based on a comparison of the respective timestamps.

9. A method of providing transparent fail-over to a client connection, the method comprising:

monitoring statistics of a client connection between a first database management system (DBMS) and a client, wherein said monitoring is performed by a connection manager of a second DBMS;

replicating data between a first file in communication with the first DBMS and a second file in communication with the second DBMS;

determining from the statistics a need, based on an unbalanced workload between the first DBMS and the second DBMS, to transparently move the client connection from the first DBMS to the second DBMS while keeping the client connection alive from a perspective of the client;

rerouting the client connection to the second DBMS; and

establishing communication between the second DBMS and the client over the client connection.

10. The method of claim 9, wherein said replicating data additionally comprises:

receiving, with the first DBMS, a data request from the client to modify the first file;

storing replication data indicating changes made to the data of the first file based on the data request;

sending a copy of the data request to the connection manager of the second DBMS; and

determining if the copy of the data request is redundant to the replication data, and when the copy of the data request is determined to be redundant to the replication data, purging one of (i) the copy of the data request and (ii) the replication data.

11. The method of claim 10, additionally comprising forwarding the non-purged data of (i) the copy of the data request or (ii) the replication data to the second DBMS.

12. The method of claim 10, additionally comprising associating a timestamp with the data request.

13. The method of claim 10, wherein said determining if the copy of the data request is redundant comprises comparing the timestamp of the data request with a timestamp of the replication data.

14. The method of claim 9, additionally comprising sending keep-alive messages to the client from the connection manager of the second DBMS.

15. The method of claim 9, additionally comprising replaying any statements from open transactions rolled back when the client connection was moved from the first DBMS.

16. The method of claim 9, wherein said determining the need includes detecting an unavailability of the first DBMS.

17. The method of claim 16, wherein the unavailability is caused by a failure of the first DBMS.

18. The method of claim 9, additionally comprising monitoring, with a connection manager of the first DBMS, a performance of the second DBMS.

19. A system for providing transparent fail-over to a client connection, the system comprising:

means for monitoring statistics of a client connection between a first database management system (DBMS) and a client, said monitoring means being associated with a second DBMS;

means for storing replication data indicating changes made to data of a first data file based on a transaction sent from the client to the first DBMS;

means for receiving a copy of the transaction;

means for determining if the copy of the transaction is redundant to the replication data, and when the copy of the transaction is determined to be redundant to the replication data, purging one of (i) the copy of the transaction and (ii) the replication data;

determining from the statistics a need to transparently move the client connection to the second DBMS while keeping the client connection alive from a perspective of the client;

rerouting the client connection to the second DBMS; and

establishing communication between the second DBMS and the client over the client connection.

20. The system of claim 19, further comprising second means for monitoring a performance of the second DBMS, wherein said second monitoring means is associated with the first DBMS.