Distributed database system utilizing an extended two-phase-commit process

• US 8,880,486 B2
• Filed: 07/27/2010
• Issued: 11/04/2014
• Est. Priority Date: 07/27/2010
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: SAP AG (SAP SE)
• Inventors: Driesen, Volker, Eberlein, Peter
• Primary Examiner(s): Alam, Hosain
• Assistant Examiner(s): JOHNSON, JOHNESE T
• Application Number:
  US12/844,662
• Publication Number:
  US 20120030184A1
• Time in Patent Office: 1,561 Days
• Field of Search: 707/703
• US Class Current: 707/703
• CPC Class Codes: G06F 16/2379 Updates performed during online database operations; commit processing
• CPC Class Codes: G06F 16/25 Integrating or interfacing systems involving database management systems

Abstract

A distributed database system is provided in which a commit coordinator ensures that transactions spanning multiple database instances are committed or rolled back consistently. The commit coordinator utilizes an extended two-phase-commit process. The extension of the two-phase-commit process enables, that if within the distributed database cohorts store redundant data for a productive operation, only one of the cohorts out of a redundancy group are required. By this, the distributed database is prepared to continue operation even during shutdown or failure of single cohorts. Related apparatus, systems, techniques and articles are also described.

Claims

1. A method for implementation in a distributed database system comprising a cluster of databases, the method comprising:

sending, by a commit coordinator in a voting phase, a query to commit message to a plurality of cohorts, each cohort being a database instance participating in the cluster of databases, at least one cohort being a cohort mirror redundantly storing data for a corresponding cohort, the query requesting the cohort to execute a transaction up to a commitment point;

receiving, by the commit coordinator, replies from the plurality of cohorts indicating whether execution of the transaction to the commitment point was successful or if execution of the transaction to the commitment point failed, wherein a reply to the query to commit message sent by the cohort mirror directly to the commit coordinator indicating that execution of the transaction to the commitment point was successful is treated as a reply indicating same by the corresponding cohort;

sending, by the commit coordinator in a completion phase, a commit message to all of the cohorts if all of the cohorts reply and all of the replies indicate that the execution of the transaction to the commitment point was successful, the commit message causing each cohort to complete the transaction and release any locks and resources held during execution of the transaction;

or

sending, by the commit coordinator in the completion phase, a rollback message to all of the cohorts if one or more of the replies indicate that the execution of the transaction to the commitment point failed, the rollback message causing each cohort to undo the transaction and release any locks and resources held during execution of the transaction;

initiating, by the commit coordinator, a restart process upon a failure of the commit coordinator; and

queuing, by the commit coordinator, without starting processing the incoming transactions until a restarted cohort executing a current transaction sends a message indicating completion of the current transaction.

2. A method as in claim 1, wherein the query to commit message includes a transaction sequence number.

3. A method as in claim 2, wherein the cohorts order execution of the transaction according to the transaction sequence number.

4. A method as in claim 1, wherein the cohorts execute the transaction to the commitment point and write a first entry to an undo log and a second entry to a redo log.

5. A method as in claim 1, wherein cohorts and their cohort mirrors form redundancy groups.

6. A method as in claim 1, wherein failure of a cohort to respond to the query to commit message within a pre-defined amount of time is treated as a reply that the execution of the transaction to the commitment point failed.

7. A method as in claim 1, wherein the cohorts send a rollback acknowledgement message to the commit coordinator in response to receiving the rollback message, and wherein the method further comprises:

undoing, by the commit coordinator, the transaction when rollback acknowledgement messages have been received from each cohort;

or

aborting, by the commit coordinator, the transaction if the rollback acknowledgement messages have not been received from each cohort.

8. A method as in claim 1, wherein at least one cohort has a cohort mirror redundantly storing data for such at least one cohort, and wherein the cohorts and/or their respective cohort mirrors send a rollback acknowledgement message to the commit coordinator, and wherein the method further comprises:

undoing, by the commit coordinator, the transaction when rollback acknowledgement messages have been received from each cohort and/or its cohort mirror;

or

aborting, by the commit coordinator, the transaction if the rollback acknowledgement messages have not been received from each cohort and/or its cohort mirror.

9. A method as in claim 1, wherein the commit coordinator is coupled to a commit controller watchdog, the commit controller watchdog monitoring whether the commit coordinator fails.

10. A method as in claim 1, further comprising:

requesting, by the commit coordinator from each cohort, information regarding transactions currently handled by the cohort.

11. A method as in claim 10, wherein the information regarding transactions currently handled by the cohort include one or more of:

transaction identification, status, and a last message sent by such cohort to the commit coordinator.

12. A method as in claim 1, further comprising:

initiating, by the commit coordinator, a fail-over process upon a determination that at least one cohort is going down.

13. A method as in claim 1, wherein the commit coordinator comprises an availability monitor module to identify if a cohort is down.

14. A method as in claim 1, wherein the commit coordinator comprises an availability manager module to notify application servers accessing the cohorts when a particular cohort is down and to initiate restarts of cohorts.

15. A method as in claim 1, wherein each cohort comprises:

a log shipping unit module to send and receive database logs.

16. A method as in claim 15, wherein each cohort comprises:

a resume manager module to manage resume processes.

17. A method as in claim 1, wherein the transaction was sent to the commit coordinator by an application server, the application server executing a transaction manager module for sending transactions to all cohorts which act as a redundancy group.

18. A method for implementation in a distributed database system comprising a cluster of databases, the method comprising:

sending a query to commit message to a plurality of cohorts and to cohort mirrors redundantly storing data for a corresponding cohort, each cohort and each cohort mirror being a database instance participating in the cluster of databases, the query requesting execution of a transaction up to a commitment point;

receiving replies from at least a portion of the plurality of cohorts and/or cohort mirrors indicating whether execution of the transaction to the commitment point was successful or if execution of the transaction to the commitment point failed, wherein a reply to the query to commit message sent by the cohort mirror directly to the commit coordinator indicating that execution of the transaction to the commitment point was successful is treated as a reply indicating same by the corresponding cohort; and

sending a commit message to all of the cohorts and each cohort mirror if the replies indicate that the execution of the transaction to the commitment point was successful, the commit message causing each cohort and each cohort mirror to complete the transaction and release any locks and resources held during execution of the transaction;

or

sending a rollback message to all of the cohorts and each cohort mirror if one or more of the replies indicate that the execution of the transaction to the commitment point failed or if a reply was not received, the rollback message causing each cohort and each cohort mirror to undo the transaction and release any locks and resources held during execution of the transaction.

19. A system comprising:

a database system having a plurality of servers running two or more redundant database instances, each server comprising memory and at least one programmable data processor;

a plurality of application servers coupled to the database system to periodically access data stored within the database system, each application server comprising memory and at least one programmable data processor;

a commit coordinator computing system coupled to the database system and the plurality of application servers, the commit coordinator computing system comprising memory and at least one programmable data processor;

wherein the commit coordinator computing system;

sends a query to commit message to a plurality of cohorts and to cohort mirrors redundantly storing data for a corresponding cohort, each cohort and each cohort mirror being a database instance, the query requesting execution of a transaction up to a commitment point;

receives replies from at least a portion of the plurality of cohorts and/or cohort mirrors indicating whether execution of the transaction to the commitment point was successful or if execution of the transaction to the commitment point failed; and

sends a commit message to all of the cohorts and each cohort mirror if the replies indicate that the execution of the transaction to the commitment point was successful, the commit message causing each cohort and each cohort mirror to complete the transaction and release any locks and resources held during execution of the transaction;

or

sends a rollback message to all of the cohorts and each cohort mirror if one or more of the replies indicate that the execution of the transaction to the commitment point failed or if a reply was not received, the rollback message causing each cohort and each cohort mirror to undo the transaction and release any locks and resources held during execution of the transaction;

wherein;

if one of the cohorts has been set down during the commit process, no further query to commit messages are sent to the cohort by the commit coordinator, and a fail-over procedure is subsequently initiated to restart and phase-in such cohort, the fail-over procedure comprising a restart and roll-forward phase followed by a registration phase followed by a phase-in phase;

a reply to the query to commit message that is sent by the cohort mirror directly to the commit coordinator and which indicates that execution of the transaction to the commitment point was successful is treated as a reply indicating same by the corresponding cohort.