Database Recovery Using Update Journal and Snapshot Volume
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database recovery methods are inefficient due to long data reading times from storage media like tapes and lack of transaction consistency, especially when dealing with large amounts of database logs and asynchronous writing.
Innovation Solution
A method that applies the update journal to a snapshot volume up to a recovery point, switches the snapshot volume to the data volume, and then applies the database log to ensure transaction consistency, reducing the need to manage all database logs and minimizing data transfer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If backup data and all DB logs are stored in storage media like tapes, then data can be preserved, but data reading time becomes excessively long
Solution Approach 1:
The patent segments the recovery process into two distinct phases: first applying the update journal to restore data blocks, then applying only necessary DB logs for transaction consistency. This segmentation allows the storage system to keep update journals in fast storage while preserving backup data in slower storage media, thereby reducing overall recovery time while maintaining data preservation.
Solution Approach 2:
The patent performs preliminary actions by maintaining update journals in advance in the storage system's fast storage. These update journals contain block-level update information that can be quickly applied to backup data during recovery, eliminating the need to read all DB logs from slow storage media like tapes, thus preserving reliability while reducing reading time.
2Reliability
If all DB logs after backup acquisition are applied to recover the database, then complete recovery is achieved, but recovery time increases when DB log volume is large
Solution Approach 1:
The patent extracts and utilizes update journal information from the storage system to identify which data blocks have been updated since the backup. By applying only the necessary DB logs corresponding to these identified blocks, the system achieves complete recovery without processing all DB logs, thereby maintaining recovery completeness while significantly reducing recovery time when DB log volume is large.
Solution Approach 2:
The update journal acts as an intermediary between the backup data and the DB logs. It provides block-level update information that guides the selective application of DB logs, serving as a mediator that enables the system to achieve complete recovery by applying only the necessary logs rather than all logs, thus reducing recovery time.
3Productivity
If the storage system recovers data for each block independently, then block-level recovery is achieved, but transaction consistency cannot be ensured due to asynchronous writing
Solution Approach 1:
The patent implements a feedback mechanism where the update journal provides block-level update information that is used to guide the selective application of DB logs. This feedback ensures that only the necessary logs are applied in the correct order, maintaining transaction consistency while enabling fast block-level recovery. The DBMS uses this feedback to determine which logs to apply and in what sequence.
Solution Approach 2:
The update journal serves as an intermediary that bridges block-level recovery and transaction consistency. It provides the information needed to selectively apply DB logs in a manner that ensures transaction consistency, while still enabling fast recovery by avoiding the application of unnecessary logs. The intermediary role of the update journal allows the system to achieve both productivity and reliability.
Data Source
AI summary
A database recovery method including a computer and a storage system, in which: the storage system includes a disk drive for storing data; the disk drive includes a data volume, a snapshot volume, a database log for storing an update log, and an update journal for storing update information of the data volume; a recovery point for indicating an end point of a range to which the update journal is to be applied and a starting point of a range to which the database log is to be applied is recorded to recover the data volume; and when the database is to be recovered, the update journal is applied to the snapshot volume up to the recovery point, the snapshot volume after the update is switched to the data volume, and the database log after the recovery point is applied to the data volume that is set by switching.