Database Initialization Using Undo Log Reversal and Redo Replay
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database systems face challenges in maintaining high availability and disaster recovery while balancing workload between primary and secondary databases, especially during high workloads, where requests may be queued or rejected due to insufficient system resources.
Innovation Solution
The method involves initializing a database image based on a recovery image containing committed and uncommitted transactions, undoing visible uncommitted transactions, generating and replaying redo logs to create invisible uncommitted transactions, and replaying transaction logs from a secondary database system, ensuring that the secondary database remains in a consistent state and can quickly resume operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the secondary database is used for load balancing during high workloads, then system throughput is improved, but the risk of request queuing and rejection increases due to insufficient system resources
Solution Approach 1:
The patent performs preliminary actions by pre-initializing the secondary database image with committed transactions and pre-processing undo logs before failover or load balancing operations. This ensures the secondary database is in a consistent state ready to immediately handle requests, preventing request queuing and rejection when switching between databases during high workloads
2Reliability
If the secondary database performs all the same tasks as the primary database, then system availability is improved through failover capability, but hardware and software requirements increase
Solution Approach 1:
The patent creates a copied database image on the secondary database that contains committed transactions from the primary database. This copy approach allows the secondary database to provide failover capability without requiring identical hardware and software configurations, as it maintains a replicated data structure rather than requiring full system parity
Solution Approach 2:
The secondary database is designed with multi-functionality, serving both as a disaster recovery backup and as a load balancing resource. By initializing the secondary database with committed transactions and maintaining it in a consistent state, the system can use the same secondary database for both failover and load balancing purposes, reducing the need for additional dedicated hardware
3Stability of the object's composition
If visible uncommitted transactions are included in the recovery image, then data consistency is improved, but the complexity of database initialization increases
Solution Approach 1:
The patent extracts visible uncommitted transactions from the recovery image by processing undo logs. This separation allows the system to maintain data consistency by tracking uncommitted transactions while removing them from the committed data portion of the recovery image, simplifying the initialization process by clearly distinguishing between committed and uncommitted changes
4Reliability
If the database system switches to the secondary database upon primary database failure, then system availability is improved, but synchronization complexity increases
Solution Approach 1:
The patent performs preliminary synchronization by pre-initializing the secondary database with committed transactions from the primary database before any failover event occurs. This advance preparation reduces the complexity of real-time synchronization during failover, as the secondary database is already in a consistent state and only needs to continue receiving transaction logs
Data Source
AI summary
A computer implemented method is provided. The method comprises initializing a first database image of a first database system based on a recovery image comprising committed transactions, visible uncommitted transactions, and undo logs associated with the visible uncommitted transactions, undoing the visible uncommitted transactions using the undo logs, generating redo logs from the undo logs, replaying the redo logs to create invisible uncommitted transactions, and after replaying the redo logs, replaying transaction logs received from a second database system. Related apparatus, systems, techniques and articles are also described.