Asynchronous Savepoint Execution in Database Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database recovery systems face inefficiencies in rapidly executing savepoints, leading to prolonged recovery times and potential downtime, especially when load balancing between primary and secondary systems, as existing methods often block log replay and require synchronous replication, which can slow down performance.
Innovation Solution
The implementation of asynchronous savepoint execution during database recovery, where modified pages are flushed to disk using a continuous disk flusher, allowing for parallel I/O operations and reducing the need for synchronous replication, thereby enabling faster recovery without blocking log replay.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If synchronous replication is used during database recovery, then data consistency between primary and secondary systems is improved, but recovery time and system downtime worsen
Solution Approach 1:
The system performs preliminary actions by continuously maintaining a secondary database system that is ready to assume primary role. The secondary system pre-synchronizes data and maintains readiness through continuous connection to the primary system, so that when failover is needed, the transition can occur rapidly without extensive synchronization delays during the actual recovery event.
2Reliability
If log replay is blocked during savepoint execution, then data integrity is improved, but recovery speed worsens
Solution Approach 1:
The recovery process is segmented into distinct phases: a first phase where savepoints are executed and a second phase where log replay continues. This segmentation allows the system to complete savepoint operations without blocking the overall log replay process, as the second phase can proceed independently once the first phase completes, thereby maintaining both data integrity and recovery speed.
3Speed
If in-memory database is used, then data access speed is improved, but data persistence and durability worsen
Solution Approach 1:
The system merges the advantages of in-memory databases with persistent storage by implementing a hybrid architecture. The primary and secondary database systems utilize in-memory storage for rapid data access during operation, while simultaneously maintaining persistent storage mechanisms and continuous replication capabilities. This combination ensures that the speed benefits of in-memory operation are retained while the persistence and durability concerns are addressed through the integrated persistent storage layer and replication protocol.
Data Source
AI summary
Recovery of a database system can be initiated by taking the database system offline. Thereafter, recovery operations specified by a redo log of the database system are replayed. During the replaying, updates to pages implicated by the recovery operations are blocked. In parallel, modified pages are flushed to physical disk storage. The database is later brought online after all of the recovery operations are replayed.