Persistent File System Objects Table for Database Crash Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Mirrored databases face challenges in accurately managing and cleaning up physical file system objects during and after crashes, leading to inefficiencies in resynchronization and disk space usage due to lack of durable recording mechanisms for file system actions and transactions.
Innovation Solution
A persistent file system objects table is used to record intentions for file system actions before they are executed, allowing for durable and accurate tracking of file system objects, enabling crash recovery and mirror resynchronization by differentiating between committed and aborted transactions and maintaining records of file system actions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If mirror resynchronization is performed after a database crash, then database availability and data redundancy are improved, but the process becomes lengthy and inefficient due to lack of information about which file system objects to clean up or re-create
Solution Approach 1:
The system performs preliminary actions by recording file system action intentions in a persistent table before crashes occur. The persistent file system objects table stores information about which objects should be created or deleted, allowing the mirror resynchronization process to quickly retrieve this pre-recorded information and avoid lengthy analysis during recovery, thus reducing resynchronization time while maintaining reliability
2Productivity
If physical file system objects are not cleaned up after aborted transactions, then disk space is wasted and performance is hampered, but there is no mechanism to accurately identify which objects should be removed
Solution Approach 1:
The persistent file system objects table serves as an intermediary between database transactions and the file system. It accurately records which file system objects should be created or deleted by aborted and committed transactions, providing the missing information needed to identify objects for cleanup, thereby improving database performance without losing information about file system objects
3Reliability
If redo operations are performed during crash recovery by replaying the transaction log, then all work is redone to ensure data consistency, but the process becomes very lengthy for large databases
Solution Approach 1:
The system extracts the essential information about file system actions from the detailed transaction log and stores it in the persistent file system objects table. During crash recovery, the system can take out only the necessary information about which objects to create or delete from this compact table, rather than replaying the entire transaction log, thus maintaining data consistency while significantly reducing recovery time for large databases
Data Source
AI summary
In a mirrored database system, a careful write of intentions to perform file system actions is recorded in a persistent file system objects table that is flushed to disk prior to the actions being taken. The table durably and accurately records identities of file system objects that were in use by the database to facilitate creation and deletion of physical file directories and files on a database during crash recovery and during mirror resynchronize. In the event of a failure, crash recovery may quickly and easily identify file system objects which need to be cleaned up by reference to the persistent file system objects table. Similarly, resynchronization of the mirror database can be performed quickly by referring to the persistent file system table data to detect changes since the last database checkpoint.