Database Replication Recovery Using a Single Transaction Bookmark

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database replication systems face inefficiencies and high costs when fault conditions occur, requiring recopying of database tables and disrupting real-time transaction monitoring.

Innovation Solution

A method utilizing a single recovery bookmark comprising an earliest open entry, latest commit entry for the current batch, and latest commit entry for the next batch to manage database transactions, allowing for fault recovery and resumption without recopying tables, using techniques like adaptive apply and transaction log analysis.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If database tables are recopied when fault conditions occur, then data consistency is restored, but downtime increases and productivity decreases

Engineering Contradiction:
Improvedata consistencyVSAvoiddowntime
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system performs preliminary actions by creating checkpoints and logging all transactions before faults occur. The transaction log captures the state of the analytics accelerator before and after replication, enabling rapid recovery by simply replaying logged transactions rather than recopying entire tables, thus restoring data consistency with minimal downtime

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Instead of copying entire database tables during recovery, the system copies only the necessary transaction log entries and replay them to restore consistency. This selective copying approach maintains reliability while dramatically reducing the time and resources needed for recovery operations

Inventive Principle:
Principle #26Copying

2Measurement precision

If multiple bookmarks are used to track transaction batches, then fault recovery precision is improved, but system complexity increases

Engineering Contradiction:
Improvefault recovery precisionVSAvoidsystem complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The system merges multiple bookmark tracking functions into a single transaction log structure. The log inherently tracks the state before and after each batch of transactions, combining what would otherwise require separate bookmarks into one unified mechanism that provides precise fault recovery capability without increasing system complexity

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The transaction log serves multiple functions simultaneously: it acts as a replication buffer, a checkpoint mechanism, a transaction history recorder, and a recovery guide. This universal structure eliminates the need for separate bookmark systems while maintaining precise tracking of transaction batches for accurate fault recovery

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Productivity

If real-time transaction monitoring is maintained during recovery, then operational continuity is preserved, but resource consumption increases

Engineering Contradiction:
Improveoperational continuityVSAvoidresource consumption
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The system maintains continuous transaction monitoring and replication operations even during recovery processes. By using the transaction log to guide recovery, the analytics accelerator can continue accepting and monitoring new transactions while simultaneously replaying logged transactions to restore consistency, ensuring operational continuity without excessive resource consumption

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS20260017152A1Recovery of a target database system
Publication Date: 2026.01.15 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US20260017152A1 patent drawing
  • US20260017152A1 patent drawing
  • US20260017152A1 patent drawing

AI summary

Disclosed herein is a computer implemented method of recovery of a target database system. The method comprises: receiving multiple database tables from a source database system to form the target database system; receiving multiple batches of database transactions. The method further comprises repeatedly performing the following for a current batch of the multiple batches of database transactions: generating a single recovery bookmark before beginning processing of the current batch, wherein the single recovery bookmark comprises: an earliest open entry for the current batch, a latest commit entry for the current batch, and a latest commit entry for a next batch of the multiple batches of database transactions; performing the sequence of database transactions for the current batch; detecting a fault condition; recovering the target database system according to a recovery protocol using the single recovery bookmark; and resuming the performance of the sequence of database transactions for the current batch.