Fast database failover

• US 5,951,695 A
• Filed: 07/25/1997
• Issued: 09/14/1999
• Est. Priority Date: 07/25/1997
• Status: Expired due to Term

• Current Assignee: Hewlett Packard Enterprise Development LP (Hewlett-Packard Enterprise Company)
• Original Assignee: Hewlett-Packard Company (HP Inc.)
• Inventors: Kolovson, Curtis P.
• Primary Examiner(s): HUA, LY
• Application Number:
  US08/900,945
• Time in Patent Office: 781 Days
• Field of Search: 395/182.14, 395/182.04, 395/182.09, 395/182.11, 395/182.17, 395/182.18, 711/161, 711/162, 707/204, 707/202, 707/19, 714/6, 714/11, 714/13, 714/20
• US Class Current: 714/16
• CPC Class Codes: G06F 11/1451 by selection of backup contents
• CPC Class Codes: G06F 11/2066 Optimisation of the communication load
• CPC Class Codes: G06F 11/2071 using a plurality of controllers

Abstract

A database system facilitates quick failover. The database system includes a primary node, a standby node and a fast interconnect between the primary node and the standby node. The primary node includes a primary buffer pool which stores pages of the database information, and a log storage which receives a log of updates for the pages within the primary buffer pool. When a page is to be updated by a primary node, the primary node sends a copy of a before update image of the page to the standby node. When the primary log writes logs of updates to the log storage, the primary node also forwards the logs of updates to the standby node.

Claims

1. A method for facilitating failover within a database system comprising the following steps:

(a) when during normal operation of a primary node, a page is to be updated by the primary node, sending a copy of a before update image of the page to a standby node;

(b) writing a log of updates for the page to a log storage; and

,

(c) forwarding the log of updates for the page to the standby node.

2. A method as in claim 1 wherein step (a) includes the following substeps:

(a.1) if the page does not exist in a buffer pool within the primary node, fetching the page from database storage into the buffer pool;

(a.2) if the page existing in the buffer pool is clean, sending the copy of the before update image of the page to the standby node; and

,

(a.3) updating the page on the primary node.

3. A method as in claim 1 wherein step (b) and step (c) are performed when the page is dirty and is being written back to a database storage.

4. A method as in claim 1 wherein step (b) and step (c) are performed when a transaction which updates the page is in a commit phase.

5. A method as in claim 1 additionally comprising the following steps performed after step (a):

(d) receiving the copy of the before update image of the page by the standby node;

(e) discarding the before update image of the page, by the standby node, when the standby node already is storing a version of the page which is identical with the before update image of the page;

(f) when the standby node already is storing a version of the page which is not identical with the before update image of the page, replacing, by the standby node, the version of the page which is not identical with the before update image of the page; and

,

(g) when the standby node is not currently storing any version of the page, storing, by the standby node, the before update image of the page.

6. A method as in claim 1 additionally comprising the following steps performed after step (c):

(d) receiving, by the standby node, the log of updates for the page;

(e) when a copy of the page does not reside in a buffer pool within the standby node, obtaining the page and placing the page into the buffer pool within the standby node; and

,

(f) performing, by the standby node, redo recovery on the page based on the log of updates for the page.

7. A method as in claim 6 additionally comprising the following step performed after step (d):

(g) inserting an entry into an active transaction cache table within the standby node, the entry indicating a transaction which updates the page and a pointer into a log spool for the standby node.

8. A method as in claim 7 additionally comprising the following step:

(h) upon the standby node receiving a commit transaction record for the transaction, deleting the entry for the transaction in the active transaction cache table.

9. A method as in claim 7 additionally comprising the following step:

(h) upon the standby node receiving a rollback record for the transaction, performing the following substeps by the standby node;

(h.1) deleting the entry for the transaction in the active transaction cache table; and

,

(h.2) performing undo recovery on the page based on the log of updates for the page.

10. A method as in claim 1 additionally comprising the following step:

(d) upon failure of the primary node, performing the following substeps;

(d.1) activating connections between the standby node and the log storage and between the standby node and database storage,

(d.2) performing undo recovery on pages within a buffer pool within the standby node to rollback updates made by transactions that were left active upon the failure of the primary node, and

(d.3) initiating a database checkpoint on the standby node in order to flush dirty pages within the buffer pool to the database storage.

11. A method as in claim 10 wherein step (d) additionally comprises the following substep:

(d.4) attempting, by the standby node, to initiate contact with a new standby node.

12. A database system comprising:

a database storage which stores database information;

a primary node, comprising;

a primary buffer pool which stores pages of the database information, and

a log storage for receiving a log of updates for the pages within the primary buffer pool; and

,

a standby node;

wherein when during normal operation of the primary node a page is to be updated by the primary node, the primary node sends a copy of a before update image of the page to the standby node, and wherein when the primary writes logs of updates to the log storage, the primary node also forwards the logs of updates to the standby node.

13. A database system as in claim 12 wherein when the page to be updated does not exist in the primary buffer pool, the primary node fetches the page from database storage into the buffer pool.

14. A database system as in claim 12 wherein the standby node comprises:

a standby buffer pool, wherein when the standby node receives the copy of the before update image of the page by the standby node;

the standby node discards the before update image of the page when the standby node already is storing in the standby buffer a version of the page which is identical with the before update image of the page,

when the standby node already is storing a version of the page in the standby buffer which is not identical with the before update image of the page, the standby node replaces the version of the page which is not identical with the before update image of the page, and

when the standby node is not currently storing any version of the page, the standby node stores the before update image of the page in the standby buffer.

15. A database system as in claim 12 wherein the standby node comprises:

a standby buffer pool; and

,

a log record reception buffer for receiving the logs of updates forwarded to the standby node by the primary node, wherein the standby node performs redo recovery on pages within the standby buffer pool based on the logs of updates received by the log record reception buffer.

16. A database system as in claim 15 additionally comprising:

a first connection between the standby node and the database storage; and

,

a second connection between the standby node and the log storage within the primary node;

wherein upon failure of the primary node,

the standby node activates the first connection and the second connection,

the standby node performs undo recovery on pages within the standby buffer pool to rollback updates made by transactions that were left active upon the failure of the primary node, and

the standby node initiates a database checkpoint in order to flush dirty pages within the standby buffer pool to the database storage.

17. A database system as in claim 16 wherein upon failure of the primary node, the standby node additionally attempts to initiate contact with a new standby node.

18. A database system as in claim 12 wherein the standby node comprises:

a standby buffer pool;

a log storage into which are stored the logs of updates forwarded to the standby node by the primary node; and

,

an active transaction cache table, entries within the active transaction cache table including

an indication of a transaction which updates a page in the standby buffer pool, and

a pointer into the log storage for the transaction.

19. A database system as in claim 18 wherein the standby node deletes a first entry from the active transaction cache table upon the standby node receiving a commit transaction record for a first transaction indicated by the entry.

20. A database system as in claim 18 wherein upon the standby node receiving a rollback record for a first transaction, the standby node deletes from the active transaction cache table a first entry which includes an indication of the first transaction, and the standby node performs an undo recovery on any pages which are modified by the first transaction.