RESTORING DATABASE CONSISTENCY INTEGRITY

• US 20150254298A1
• Filed: 02/27/2015
• Published: 09/10/2015
• Est. Priority Date: 03/06/2014
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Bourbonnais, Serge, D'Costa, Austin F. M., Fuh, You-Chin, Teng, James Z., Yu, Tyrone
• Granted Patent: US 9,875,266 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 11/2094 Redundant storage or storage space G06F11/2056 takes precedence
• CPC Class Codes: G06F 16/2282 Tablespace storage structures; Management thereof
• 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: G06F 16/273 Asynchronous replication or reconciliation
• CPC Class Codes: G06F 2201/80 Database-specific techniques
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency ensuring consistency in mirrored systems G06F11/2064
• CPC Class Codes: G06F 2201/835 Timestamp

Abstract

Techniques for restoring point-in-time and transaction consistency across consistency groups between a first and a second independent database management system (DBMS) for a disaster recovery. Several consistency groups (CGs) are defined for replication. For each CG in the first DBMS data changes are transmitted to a second DBMS. A timestamp representing a most recently received commit log record or a heartbeat during periods of inactivity for a CG is stored in a database table at regular intervals. At regular intervals, the timestamp is compared with timestamps for other CGs to identify a common time at which data to be applied to the CGs in the second DBMS have been received into a recoverable data store. The received data is applied to the CGs in the second DBMS up to the common time.

Claims

1. A method for restoring transaction consistency across consistency groups between a first and a second independent database management system for a disaster recovery, comprising:

defining a plurality of consistency groups, wherein each consistency group in the first database management system uses a separate transmission channel to transmit data changes pertaining to the consistency group to a corresponding consistency group at the second database management system;

in response to the second database management system having received data from log records from the first database management system, identifying a timestamp representing a most recently received commit log record and storing the timestamp in a database table;

comparing the timestamp with timestamps for other consistency groups to identify a lowest common commit point representing a common time at which data to be applied to the consistency groups in the second database management system have been received into a recoverable data store; and

applying the received data to the consistency groups in the second database management system up to the identified lowest common commit point.

2. The method of claim 1, wherein applying the received data to the consistency groups in the second database management system is performed only in response to having received timestamps for each consistency group in the second database management system.

3. The method of claim 1, further comprising:

sending a heartbeat message with a timestamp greater than a last replicated commit timestamp for a consistency group in response to determining that there is no data to replicate for the consistency group.

4. The method of claim 1, wherein the first databases management system and the second database management system are used in an active/active configuration.

5. The method of claim 1, further comprising:

temporarily persisting the received data in a recoverable staging area; and

independently selecting from the staging area, by one or more replication apply programs, subsets of the received data to be applied to the consistency groups in the second database management system.

6. The method of claim 5, wherein the recoverable staging area is located in one of:

the second database management system, and in a queuing system.

7. The method of claim 5, wherein:

the replication apply programs are operable to suspend an apply in response to data having been applied up to the identified lowest common commit point, and the suspended apply lasts until the replication apply programs determine a subsequent lowest common commit point to which changes are to be applied.

8. The method of claim 5, further comprising:

monitoring the state of the staging area to determine whether the lowest common commit point for which all messages containing sub-transactions to be applied in the second database management system have been received.

9. The method of claim 8, further comprising:

in response to determining that the lowest common commit point for which all messages containing sub-transactions to be applied in the second database management system have been received, notifying the other participant apply programs and applying, by the replication apply programs the subsets of data to the consistency groups in the second database management system.

10. The method of claim 1, further comprising:

prior to failover for a disaster from the first database management system to the second database management system, discarding changes beyond the lowest common commit point among all transmission channels.