HIGH AVAILABILITY VIA DATA SERVICES

• US 20080034251A1
• Filed: 10/17/2007
• Published: 02/07/2008
• Est. Priority Date: 10/02/2003
• Status: Active Grant

• Current Assignee: Progress Software Corporation
• Original Assignee: Progress Software Corporation
• Inventors: Singhal, Vivek, Emmons, Ian
• Granted Patent: US 7,827,151 B2
• Time in Patent Office: Days
• US Class Current: 714/5
• CPC Class Codes: G06F 11/1451 by selection of backup contents
• CPC Class Codes: G06F 11/1469 Backup restoration techniques
• CPC Class Codes: G06F 11/1482 by means of middleware or OS functionality
• CPC Class Codes: G06F 11/1658 Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
• 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/10 File systems; File servers
• CPC Class Codes: G06F 16/20 of structured data, e.g. relational data
• CPC Class Codes: G06F 16/273 Asynchronous replication or reconciliation
• CPC Class Codes: G06F 2201/80 Database-specific techniques
• CPC Class Codes: G06F 2201/805 Real-time
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

Application-level replication, the synchronization of data updates within a cluster of application servers, may be provided by having application servers themselves synchronize all updates to multiple redundant databases, precluding the need for database-level replication. This may be accomplished by first sending a set of database modifications requested by the transaction to a first database. Then a message may be placed in one or more message queues, the message indicating the objects inserted, updated, or deleted in the transaction. Then a commit command may be sent to the first database. The set of database modifications and a commit command may then be sent to second database. This allows for transparent synchronization of the database and quick recovery from a database failure, while imposing little performance or network overhead.

Claims

1. A method for failover from a failure of a first database during processing of a transaction, the transaction requesting a set of database modifications, the method comprising:

detecting a failure in the first database;

placing a message in one or more message queues, said message indicating objects inserted, updated, or deleted in the transaction, unless said message has already been placed;

sending the requested set of database modifications and a commit command to a second database; and

avoiding the first database in future transaction until the first database is restored.

2. The method of claim 1, wherein the method is performed by an application server.

3. The method of claim 2, further comprising:

sending a cache synchronization message to other application servers sharing the same cluster as said application server, said cache synchronization message including an indication that the first database is down.

4. The method of claim 1, wherein the set of database modifications comprises a set of SQL insert, update, and/or delete commands.

5. The method of claim 1, wherein said message contains a serialized representation of objects inserted, updated, or deleted in the transaction.

6. The method of claim 1, further comprising:

indexing messages contained in said message queue for rapid access.

7. The method of claim 3, further comprising:

receiving said cache synchronization message at another application server;

extracting a transaction ID from said cache synchronization message; and

discarding messages containing said transaction ID from one or more message queues.

8. The method of claim 3, wherein said sending the requested set of database modifications and a commit command to a second database and said sending a cache synchronization message are performed asynchronously on separate threads.

9. A method for failover from a failure of a second database during processing of a transaction, the transaction requesting a set of database modifications, the method comprising:

detecting a failure in the second database;

sending a cache synchronization message to other application servers sharing the same cluster as an application server executing the method, said cache synchronization message including an indication that the second database is down; and

avoiding the second database in future transaction until the first database is restored.

10. The method of claim 9, wherein the set of database modifications comprises a set of SQL insert, update, and/or delete commands.

11. The method of claim 9, further comprising:

receiving said cache synchronization message at another application server;

extracting a transaction ID from said cache synchronization message; and

discarding messages containing said transaction ID from one or more message queues.

12. An apparatus for failover of a first database during processing of a transaction, the transaction requesting a set of database modifications, the apparatus comprising:

a first database failure detector;

a message queue message inserter coupled to said first database failure detector;

a second database modification and commit command sender coupled to said message queue message inserter; and

a first database avoider coupled to said first database failure detector.

13. The apparatus of claim 12, wherein the apparatus is located on an application server.

14. The apparatus of claim 12, further comprising:

a cache synchronization message application server sender coupled to said first database failure detector.

15. The apparatus of claim 12, further comprising:

a message queue message indexer coupled to said message queue message inserter.

16. An apparatus for failover from a failure of a second database during processing of a transaction, the transaction requesting a set of database modifications, the apparatus comprising:

a second database failure detector;

a cache synchronization message application server sender coupled to said second database failure detector; and

a second database avoider coupled to said second database failure detector.

17. An apparatus for failover from a failure of a first database during processing of a transaction, the transaction requesting a set of database modifications, the apparatus comprising:

means for detecting a failure in the first database;

means for placing a message in one or more message queues, said message indicating objects inserted, updated, or deleted in the transaction, unless said message has already been placed;

means for sending the requested set of database modifications and a commit command to a second database; and

means for avoiding the first database in future transaction until the first database is restored.

18. The apparatus of claim 17, wherein the apparatus is located on an application server.

19. The apparatus of claim 18, further comprising:

means for sending a cache synchronization message to other application servers sharing the same cluster as said application server, said cache synchronization message including an indication that the first database is down.

20. The apparatus of claim 17, wherein the set of database modifications comprises a set of SQL insert, update, and/or delete commands.

21. The apparatus of claim 17, wherein said message contains a serialized representation of objects inserted, updated, or deleted in the transaction.

22. The apparatus of claim 17, further comprising:

means for indexing messages contained in said message queue for rapid access.

23. The apparatus of claim 18, further comprising:

means for receiving said cache synchronization message at another application server;

means for extracting a transaction ID from said cache synchronization message; and

means for discarding messages containing said transaction II) from one or more message queues.

24. The apparatus of claim 18, wherein said sending the requested set of database modifications and a commit command to a second database and said sending a cache synchronization message are performed asynchronously on separate threads.