Asynchronous Redo Shipping with Recovery Count for Zero Data Loss
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database configurations with synchronous redo transport mode ensure zero data loss but impact primary database performance, while asynchronous transport mode does not guarantee zero data loss during primary database failures.
Innovation Solution
Implementing asynchronously replicated redo logs with a recovery count mechanism to detect inconsistency and ensure zero data loss by rolling forward the standby database based on recovery counts and redo log consistency, allowing for conditional replay of redo entries.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If synchronous redo transport mode is used to guarantee zero data loss, then data reliability is improved, but primary database performance deteriorates due to increased transaction commit latency and decreased throughput
Solution Approach 1:
The patent segments the redo transport process by introducing multiple standby databases instead of a single standby. This allows the primary database to ship redo data to multiple standbys in parallel, distributing the I/O load and reducing the performance impact on the primary database while maintaining zero data loss guarantee through synchronous acknowledgment from at least one standby.
Solution Approach 2:
The patent adds a dimensional aspect to redo transport by implementing multi-threaded asynchronous I/O operations. Instead of single-threaded sequential processing, multiple threads operate simultaneously to ship redo data to different standby databases, transforming the transport process from a linear bottleneck into a parallel multi-dimensional operation that improves throughput while maintaining reliability.
2Productivity
If asynchronous redo transport mode is used to improve primary database performance, then productivity is improved, but data reliability deteriorates because zero data loss cannot be guaranteed during primary database failures
Solution Approach 1:
The patent implements a feedback mechanism where standby databases send acknowledgments back to the primary database confirming receipt of redo data. The primary database tracks which standby databases have received which redo logs, and this feedback information is used to determine when zero data loss has been achieved. This allows asynchronous transport with synchronous reliability guarantees.
Solution Approach 2:
The patent performs preliminary actions by having standby databases pre-allocate and prepare to receive redo data before failures occur. The system proactively ships redo data to multiple standbys in advance, so that when a failure occurs, the most recent redo data is already available at the standby, ensuring zero data loss without blocking the primary database.
3Productivity
If multiple standby databases are introduced to distribute I/O load, then device complexity increases, but this enables parallel asynchronous I/O operations that improve overall system throughput
Solution Approach 1:
The patent makes each standby database multi-functional: they can receive redo data from the primary database, act as failover targets, and provide acknowledgment feedback. This universal design allows the same standby infrastructure to serve multiple purposes simultaneously, reducing the need for additional specialized components and justifying the added complexity through enhanced functionality and throughput.
Data Source
AI summary
Herein are techniques of zero data loss with asynchronously replicated redo logs. In an embodiment, a first server instance (FSI) of a plurality of server instances (PSI) of a primary database (PDB) sends, to a standby database (SDB) during an shutdown of FSI, a first recovery count (RC) and a remainder of an instance redo log (IRL). In response to recovering FSI, a second server instance of PSI increments a recovery counter to a second RC (SRC), publishes SRC to PSI, and sends SRC to SDB. After restarting FSI, FSI makes a change to contents of PDB, and stores, into IRL, a redo entry that defines the change. During failover, a database management system (DBMS) detects whether RCs associated with FSRL and SSRL are unanimous. If unanimous, DBMS fully rolls forward SDB by replaying FSRL and SSRL. Otherwise, DBMS limits replay and indicates that FSRL and SSRL might be inconsistent.