Database Rollback Processor Using Change Logs for Arbitrary Time Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional database recovery methods are limited by the need for time-consuming and resource-intensive snapshot generation, which can lead to database unavailability and restrict the ability to revert to arbitrary points in time, especially in failover and replication scenarios where immediate data consistency is crucial.
Innovation Solution
The method involves identifying snapshots and logs to generate a restore snapshot of the data dictionary, allowing for the replication of changes made to logical structures in the primary database, enabling database rollback to an arbitrary point independent of physical structure, and facilitating failover without locking the main database, thus allowing continuous updates and reducing the need for costly snapshot generation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional snapshot generation methods are used for database recovery, then data consistency can be restored, but the process is time-consuming and resource-intensive, leading to database unavailability
Solution Approach 1:
The system performs preliminary actions by continuously maintaining change logs and data snapshots in advance of any recovery operation. These logs record all data modifications with timestamps and change details, so when recovery is needed, the system can immediately apply or rollback changes without generating new snapshots, eliminating the time-consuming snapshot generation step while ensuring data consistency
Solution Approach 2:
The invention creates and maintains copies of the database state through change logs that capture all modifications. Instead of generating new snapshots during recovery, the system uses these pre-existing logs to reconstruct previous states by reversing recorded changes, thereby restoring data consistency without the downtime associated with conventional snapshot creation
2Adaptability or versatility
If snapshots are generated for arbitrary time points, then flexibility in recovery timing is improved, but resource consumption and system complexity increase
Solution Approach 1:
The system performs preliminary action by continuously recording all data changes in change logs with timestamps as they occur. This continuous logging enables recovery to any arbitrary time point without generating additional snapshots, as the logs already contain the information needed to reconstruct any past state. This approach provides full recovery flexibility while avoiding the resource consumption of creating and storing multiple point-in-time snapshots
Solution Approach 2:
The invention implements a dynamic recovery approach where the system maintains a single evolving database state with associated change logs, rather than static multiple snapshots. This dynamic model allows flexible recovery to any time point by selectively applying or rolling back changes from the logs, providing adaptability without the resource overhead of maintaining numerous static snapshots
3Reliability
If the main database is locked during snapshot generation, then data consistency is ensured, but operational availability is reduced
Solution Approach 1:
The system uses change logs as copies of the database state evolution rather than locking the main database during snapshot operations. The logs capture all modifications with sufficient detail to reconstruct any past state, enabling consistency verification and recovery without interrupting database operations. This copying approach maintains both data consistency and operational availability simultaneously
Solution Approach 2:
The system performs preliminary action by continuously maintaining change logs that record all data modifications with timestamps and change details. This ongoing logging provides a ready-made mechanism for verifying data consistency at any point in time without requiring database locks, thus ensuring reliability while preserving full operational availability
4Reliability
If identical physical hardware arrangements are duplicated for standby sites, then failover reliability is improved, but cost increases
Solution Approach 1:
The invention applies copying at the data level rather than requiring physical hardware duplication. Change logs capture the complete evolution of database state, enabling any database version to be reconstructed on different hardware configurations. This allows standby sites to use different physical hardware arrangements while maintaining failover reliability through logical data reconstruction
Solution Approach 2:
The system implements universality by creating hardware-agnostic data representations through change logs. The logging mechanism captures logical data changes independent of physical storage structure, allowing the same data to be restored on diverse hardware platforms. This multi-functionality enables failover to alternative hardware configurations without requiring identical physical arrangements, reducing hardware costs while maintaining reliability
Data Source
AI summary
A database rollback processor allows rollback, or rewind, of the data and metadata to a point at which a failover or other metadata change occurred, therefore “rewinding” the metadata to a previous consistent point. The rollback processor identifies transaction entries in a redo log resulting in changes to the metadata. The changes are identified backward to a target recovery time. Transactions affecting the metadata are stored in a stack. The transactions are then backed out of the metadata according to the stack to restore the metadata to the state at the target recovery time. Data changes from the redo log may then be applied to the corresponding metadata as it existed at the target recovery time. Since the target recovery time is not bound by the timing of the snapshots, but rather may be at an arbitrary point chosen as the target recovery time, a failover, replication or recovery operation need not rely on the snapshot time.