Database Replication Host Takeover and Version Mismatch Handling

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing database management systems face challenges in maintaining high availability and minimizing downtime during host upgrades and parameter changes, especially when hosts performing source and replica roles are running different versions, leading to communication issues and potential data corruption.

Innovation Solution

Implementing a network layer that applies an allow list to requests between hosts, ensuring that only permitted requests, such as replication-related requests, are directed to replica hosts running different versions, while redirecting other requests to source hosts. Additionally, upgrading hosts in a serial manner to avoid system downtime and using asynchronous replication for secondary database management systems to reduce recovery time objectives.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If hosts are upgraded in parallel to reduce total upgrade time, then productivity improves, but system reliability deteriorates due to communication issues between hosts running different versions

Engineering Contradiction:

Improveupgrade speedVSAvoidsystem stability

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The upgrade process is segmented into serial phases where hosts are upgraded one at a time rather than in parallel. The system divides the upgrade operation into discrete steps: upgrade first host, verify stability, then upgrade second host. This segmentation prevents communication conflicts between mismatched versions while maintaining overall upgrade productivity.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by upgrading and stabilizing the first host before initiating the upgrade of the second host. This preliminary upgrade establishes a stable baseline version that the second host can safely communicate with, preventing version mismatch issues before they occur.

Inventive Principle:

Principle #10Preliminary action

2Manufacturing precision

If synchronous replication is used to ensure data consistency, then manufacturing precision improves, but loss of time increases due to waiting for confirmation from secondary system

Engineering Contradiction:

Improvedata consistencyVSAvoidcommit time

Core Design Contradiction:

Manufacturing precisionVSLoss of time

Solution Approach 1:

The system applies partial synchronous replication by selectively using synchronous confirmation only for critical data operations while allowing asynchronous processing for non-critical updates. This partial approach maintains data consistency for essential transactions without requiring time-consuming confirmation for all operations, thus reducing overall commit time while preserving necessary data integrity.

Inventive Principle:

Principle #16Partial or excessive action

Solution Approach 2:

The system dynamically changes the replication mode parameter based on operation priority and system state. For critical operations, synchronous replication is activated to ensure data consistency; for non-critical operations, asynchronous replication is used to minimize time loss. This parameter adjustment optimizes the balance between consistency and speed.

Inventive Principle:

Principle #35Parameter changes

3Device complexity

If the secondary database management system is kept simple without host replication, then device complexity reduces, but reliability deteriorates when the primary system fails

Engineering Contradiction:

Improvesystem structureVSAvoidfailover capability

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The secondary database management system employs dynamic host replication where replica hosts are created and activated only when needed for failover scenarios. During normal operation, the secondary system maintains a simpler structure without active replica hosts. When the primary system fails, the secondary system dynamically provisions replica hosts to assume source roles, providing failover capability only when required, thus balancing complexity and reliability.

Inventive Principle:

Principle #15Dynamics

4Productivity

If redo logs are replayed out of order to improve processing speed, then productivity improves, but manufacturing precision deteriorates due to data corruption

Engineering Contradiction:

Improveredo log processing speedVSAvoiddata integrity

Core Design Contradiction:

ProductivityVSManufacturing precision

Solution Approach 1:

The system replaces the mechanical sequential replay mechanism with a coordinated parallel replay system that uses software-based ordering control. Instead of physically replaying logs in strict sequence, the system uses metadata tracking and coordination logic to ensure logical ordering is maintained while allowing physical processing to occur in parallel, thus achieving both speed and data integrity.

Inventive Principle:

Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS12332913B2Database replication with host replication at asynchronously replicated system

Publication Date: 2025.06.17 SAP SE

AI summary

Various examples are directed to systems and methods for operating a primary database management system and a secondary database management system. The secondary database management system may receive a takeover request indicating that the secondary database management system is to assume a role of the primary database system. The secondary database management system may determine that a last valid commit of a first host of the secondary database system is an oldest last valid commit. The secondary database management system may revert to a first state of the primary database management system corresponding to the last valid commit of the first host. The secondary database management system may be configured to assume the role of the primary database management system.