Systems and methods for managing replicated database data in dirty and clean shutdown states

• US 9,047,357 B2
• Filed: 02/28/2014
• Issued: 06/02/2015
• Est. Priority Date: 12/10/2008
• Status: Active Grant

• Current Assignee: CommVault Systems Incorporated
• Original Assignee: CommVault Systems Incorporated
• Inventors: Ngo, David
• Primary Examiner(s): Waldron, Scott A
• Application Number:
  US14/193,945
• Publication Number:
  US 20140181022A1
• Time in Patent Office: 459 Days
• Field of Search: 707/634, 707/638, 707/639, 707/649, 707/683, 707/684
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 11/2094 Redundant storage or storage space G06F11/2056 takes precedence
• 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/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/84 Using snapshots, i.e. a logical point-in-time copy of the data

Abstract

Systems and methods for replicating database data in a dirty shutdown state and generating copies of the replicated data in a clean shutdown state. For example, systems can include a tracking module (e.g., a filter driver) that monitors transactions from a database application to a source database stored on a source storage device to generate log entries having at least one marker indicating a known good state of the application. The systems further include a computer coupled to a target storage device comprising a target database and log files. The computer processes the transactions, based on the log entries, to replicate data to a target database on the target storage device; performs a first snapshot on data stored in the target database existing in a dirty shutdown state; replays into the target database data stored in the log files to put the target database in a clean shutdown state; copies the target database in the clean shutdown state; and reverts the target database back to the dirty shutdown state in which the target database existed at the time of the first snapshot.

Claims

1. A system for performing data management operations, the system comprising:

at least one target computer comprising computer hardware that communicates with at least one source computer to receive information about a source database stored on a first storage device;

at least one second storage device in communication with the target computer;

wherein the target computer replicates at least a portion of the source database to generate a target database on the second storage device, the target database existing in a dirty shutdown state at a first time;

wherein the target computer copies at least a portion of the target database in the dirty shutdown state to create a first copy, the first copy stored in the dirty shutdown state;

at a second time subsequent to creating the first copy, the target computer commits a plurality of data transactions to the target database that puts the target database into a clean shutdown state;

wherein the target computer copies at least a portion of the target database in the clean shutdown state to create a second copy that includes data corresponding to the plurality of committed data transactions, wherein the second copy is stored in the clean shutdown state; and

wherein the target computer reverts the target database in the clean shutdown state back to the dirty shutdown state based on differences between the first copy in the dirty shutdown state and the second copy in the clean shutdown state.

2. The system of claim 1 wherein the source database and the target database are out of sync following the committing of the plurality of data transactions to the target database.

3. The system of claim 1 wherein the target computer commits the plurality of data transactions into the target database prior to the plurality of data transactions being committed into the source database.

4. The system of claim 1 wherein at least one of the plurality of data transactions comprise a marker indicative of a time of a known good state of a database application.

5. The system of claim 1 wherein copying the portion of the target database comprises a point-in-time snapshot operation.

6. The system of claim 1 wherein the target computer further comprises a replication module having a plurality of threads that commit the plurality of data transactions.

7. The system of claim 1 wherein the target computer comprises at least one application programming interface that commits the plurality of data transactions.

8. The system of claim 1 further comprising a filter driver that monitors the plurality of data transactions associated with the source database and generates log entries.

9. The system of claim 1 wherein the second copy is a read-only copy of the target database.

10. The system of claim 1 wherein creating the target database occurs without shutting down a database application.

11. A method for performing data management operations, the method comprising:

replicating at least a portion of a source database to generate a target database on a second storage device, the target database existing in a dirty shutdown state at a first time;

copying at least a portion of the target database in the dirty shutdown state to create a first copy, the first copy stored in the dirty shutdown state;

at a second time subsequent to creating the first copy, committing a plurality of data transactions to the target database that puts the target database into a clean shutdown state;

copying at least a portion of the target database in the clean shutdown state to create a second copy that includes data corresponding to the plurality of committed data transactions, wherein the second copy is stored in the clean shutdown state; and

reverting the target database in the clean shutdown state back to the dirty shutdown state based on differences between the first copy in the dirty shutdown state and the second copy in the clean shutdown state.

12. The method of claim 11 wherein the source database and the target database are out of sync following the committing of the plurality of data transactions to the target database.

13. The method of claim 11 wherein committing the plurality of data transactions into the target database occurs prior to the plurality of data transactions being committed into the source database.

14. The method of claim 11 wherein at least one of the plurality of data transactions comprise a marker indicative of a time of a known good state of a database application.

15. The method of claim 11 wherein copying the portion of the target database comprises a point-in-time snapshot operation.

16. The method of claim 11 wherein committing the plurality of data transactions comprises using a replication module having a plurality of threads.

17. The method of claim 11 wherein committing the plurality of data transactions comprises using a programming interface.

18. The method of claim 11 further comprising monitoring the plurality of data transactions associated with the source database with a filter driver and generating log entries.

19. The method of claim 11 wherein the second copy is a read-only copy of the target database.

20. The method of claim 11 wherein creating the target database occurs without shutting down a database application.