Method for highly available transaction recovery for transaction processing systems

• US 7,620,842 B2
• Filed: 07/28/2006
• Issued: 11/17/2009
• Est. Priority Date: 02/22/2002
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: BEA Systems Incorporated (Oracle Corporation)
• Inventors: Somogyi, Alexander J., Fung, Priscilla C.
• Primary Examiner(s): Maskulinski; Michael C
• Application Number:
  US11/495,239
• Publication Number:
  US 20060271814A1
• Time in Patent Office: 1,208 Days
• Field of Search: 714/4, 714/10
• US Class Current: 714/4.11
• CPC Class Codes: G06F 11/1662 the resynchronized component or unit being a persistent storage device re-synchronization of failed mirror storage G06F11/2082; rebuild or reconstruction of parity RAID storage G06F11/1008
• CPC Class Codes: G06F 11/2028 eliminating a faulty processor or activating a spare
• 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: H04L 1/22 using redundant apparatus to increase reliability

Abstract

A highly available transaction recovery service migration system in accordance with one embodiment of the present invention implements a server'"'"'s Transaction Recovery Service (TRS) as a migratable service. In one embodiment of the present invention, the TRS is a server instance or software module implemented in JAVA. The TRS migrates to an available server that resides in the same cluster as the failed server. The migrated TRS obtains the TLOG of the failed server, reads the transaction log, and performs transaction recovery on behalf of the failed server. The migration may occur manually or automatically on a migratable services framework. The TRS of the failed server migrates back in a fail back operation once the failed primary server is restarted. Failback operation may occur whether recovery is completed or not. This expedites recovery and improves availability of the failed server thereby preserving the efficiency of the network and other servers.

Claims

1. A method for recovering transactions comprising:

providing a cluster of servers executing on one or more computers, wherein each computer includes a computer readable medium and a processor operating thereon;

providing, at each of the servers within the cluster

a transaction recovery service, and

a corresponding transaction log for which the transaction recovery service has ownership and which is stored on a shared computer readable medium also accessible by other servers in the cluster;

detecting, within the cluster, a failure of a primary server associated with a first transaction recovery service and a first transaction log stored on the shared computer readable medium, wherein the first transaction log includes records of a current transaction and participants being coordinated by the primary server for participation in the current transaction;

performing failover migration of the first transaction recovery service from the failed primary server to a back-up server in the cluster that also has access to the shared computer readable medium, and maintaining ownership by the first transaction recovery service of the first transaction log;

performing transaction recovery for the failed primary server by the first transaction recovery service at the back-up server, using the first transaction log, and including processing any unfinished transactions; and

after primary server transaction recovery is complete, performing failback migration of the first transaction recovery service from the back-up server to the primary server to allow the primary server to service new or subsequent transactions.

2. The method of claim 1 wherein said first performing failover migration includes:

initiating failover migration by an administrator.

3. The method of claim 2 wherein said initiating failover migration by an administrator includes an administrator issuing a migration command.

4. The method of claim 3 wherein the issuing a migration command includes a user manually issuing a migration command using a console implemented as a GUI system.

5. The method of claim 3 wherein the issuing a migration command includes a user manually issuing a migration command using a command line.

6. The method of claim 1 wherein the back-up server has multiple transaction recovery services residing on the back-up server, each transaction recovery service corresponding to a different primary server and a corresponding transaction log.

7. The method of claim 1 wherein said first performing failover migration includes:

detecting that the primary server has failed;

moving the transaction recovery service to the back-up server; and

activating the transaction recovery service on the back-up server.

8. The method of claim 7 wherein moving the transaction recovery service to the back-up server includes manually issuing a migration command by a user.

9. The method of claim 7 wherein moving the transaction recovery service to the back-up server includes automatically moving the transaction recovery service to the back-up server by a migration service framework.

10. The method of claim 7 wherein the transaction recovery service is registered with a migration service framework.

11. The method of claim 7 wherein moving the transaction recovery service to the back-up server is implemented by a command line administration tool implemented as a JAVA program.

12. The method of claim 7 wherein moving the transaction recovery service to the back-up server is implemented by a JAVA MBean.

13. The method of claim 1 wherein said initiating failback migration includes:

detecting the startup of the primary server.

14. The method of claim 1 wherein said completing failback migration includes:

deactivating the transaction recovery service on the back-up server;

moving the transaction recovery service from the back-up server to the primary server; and

activating the transaction service on the primary server.

15. The method as claimed in claim 1 wherein initiating failback migration includes completing recovery for the primary server.

16. The method of claim 1 wherein said first performing failover migration is done automatically without user input, said second performing recovery is done automatically without user input, and said third performing failback migration is done automatically without user input.

17. The method of claim 1 wherein said transaction recovery service is a server instance implemented in java.

18. A method for performing transaction recovery comprising:

(a) providing a cluster of servers executing on one or more computers, wherein each computer includes a computer readable medium and a processor operating thereon;

(b) providing, at each of the servers within the cluster

a transaction recovery service, and

a corresponding transaction log for which the transaction recovery service has ownership and which is stored on a shared computer readable medium also accessible by other servers in the cluster;

(c) detecting a first server has failed, the first server having a first transaction log on the shared computer readable medium and a first transaction recovery service wherein the transaction log includes records of at least one transaction and related participants being coordinated by the first server for the at least one transaction;

(d) moving the first transaction recovery service to a second server wherein the second server has access to the shared computer readable medium and wherein the first transaction recovery service maintains ownership of the first transaction log;

(e) activating the first transaction recovery service on the second server;

(f) performing transaction recovery on behalf of the first server by the first transaction recovery service at the second server, using the first transaction log, while the first transaction recovery service resides on the second server wherein transaction recovery includes processing any unfinished transactions;

(g) completing transaction recovery on behalf of the first server by the first transaction recovery service;

(h) deactivating the first transaction recovery service on the second server;

(i) moving the first transaction recovery service from the second server to the first server to service new or subsequent transactions, wherein moving the first transaction recovery service from the second server to the first server is completed after transaction recovery on behalf of the first server by the first transaction recovery service is completed; and

(h) activating the first transaction recovery service on the first server.

19. The method as claimed in claim 18 wherein said (b) moving the first transaction recovery service to a second server is initiated by a user.

20. The method as claimed in claim 19 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a console implemented as a GUI system.

21. The method as claimed in claim 19 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a command line.

22. The method as claimed in claim 19 wherein step (b) moving the first transaction recovery service as initiated by a user includes manually issuing a migration command using a JMX MBean.

23. The method of claim 18 wherein said transaction recovery service is a server instance implemented in java.

24. A method for manually performing failback migration from a backup server to a primary server after transaction recovery on a primary server is complete comprising:

detecting, within the cluster, a failure of a primary server associated with a first transaction recovery service (TRS) and a first transaction log (TLOG) stored on the shared computer readable medium, wherein the first transaction log includes records of a current transaction and participants being coordinated by the primary server for participation in the current transaction;

performing failover migration of the first TRS from the failed primary server to a backup server in the cluster that also has access to the shared computer readable medium, and maintaining ownership by the first TRS of the first TLOG;

completing transaction recovery for the failed primary server by the first TRS associated with the primary server and residing on the backup server wherein transaction recovery includes using the first TLOG corresponding to the failed primary server to commit each unfinished transaction included in the first TLOG;

requesting a migratable framework to migrate the first TRS from the backup server to the primary server, the backup server making the request to the migratable framework;

deactivating the first TRS residing on the backup server by the migratable framework, wherein deactivating the first TRS includes the migratable framework calling a JAVA method residing in the first TRS to deactivate the first TRS on the backup server; and

migrating the first TRS from the backup server to the primary server by the migratable framework after primary server transaction recovery is complete to service new or subsequent transactions, wherein the primary server regains ownership of the first TLOG corresponding to the primary server upon primary server restart.

25. In a cluster of servers, a server high availability method comprising the step of performing transaction recovery in a backup server using a transaction recovery service and a transaction log, wherein the transaction log includes records of at least one transaction and related participants being coordinated for the at least one transaction and wherein transaction recovery includes processing any unfinished transactions, stored in a memory shared between the backup server and a failed server before the step of restarting the failed server and migrating the transaction recovery service from the backup server to the failed server after transaction recovery is complete.

26. In a cluster of servers, a server high availability method comprising the step of performing transaction recovery in a backup server using a transaction recovery service and a transaction log, wherein the transaction log includes records of at least one transaction and related participants being coordinated for the at least one transaction and wherein transaction recovery includes processing any unfinished transactions, before the step of restarting a failed server and migrating the transaction recovery service from the backup server to the failed server after transaction recovery is complete.