High Availability Database Management System Automatic Failover Mechanism

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database management systems (DBMS) face challenges in providing continuous service without data loss when errors occur, as existing backup and replication methods can result in data inconsistencies and require manual intervention, and may necessitate changes to application programs.

Innovation Solution

A high availability DBMS method using multiple broker and server nodes that automatically switches between main and sub-server nodes, enabling continuous service by synchronizing transaction logs and maintaining data integrity without altering application programs.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If periodic backup of operational DB is performed, then data loss is prevented, but data generated after backup interval is lost and system load increases

Engineering Contradiction:
Improvedata loss preventionVSAvoiddata loss after backup interval
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The system performs preliminary actions by continuously replicating data to a standby DBMS in real-time before any potential error occurs. This continuous replication ensures that the standby database is always synchronized with the operational database, eliminating data loss between backup intervals while maintaining system reliability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The invention creates a copy of the operational database through asynchronous replication to a standby DBMS. This copying mechanism continuously replicates data changes, ensuring the standby database mirrors the operational database state, thereby preventing data loss without requiring frequent periodic backups.

Inventive Principle:
Principle #26Copying

2Reliability

If asynchronous replication is used to generate standby DBMS, then continuous service is provided, but data inconsistency occurs between original and replicated DB

Engineering Contradiction:
Improvecontinuous service availabilityVSAvoiddata consistency between databases
Core Design Contradiction:
ReliabilityVSStability of the object's composition

Solution Approach 1:

The system implements feedback mechanisms through transaction logs that track all data changes in the operational database. These logs are continuously monitored and replicated to the standby database, ensuring that any data inconsistency is detected and corrected by applying the same transactions in the same sequence, thereby maintaining data consistency while providing continuous service.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

Transaction logs serve as an intermediary mechanism between the operational database and standby database. The logs capture all data changes and transmit them in sequential order to the standby database, ensuring consistent replication without direct connection issues between the two databases, thus maintaining data integrity while enabling continuous service.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Ease of operation

If manual determination is performed for DB failover, then service continuity is interrupted, but system control is maintained

Engineering Contradiction:
Improvemanual control over failoverVSAvoidservice interruption time
Core Design Contradiction:
Ease of operationVSLoss of time

Solution Approach 1:

The system implements self-service automation through monitoring modules that continuously detect errors in the operational database. When an error is detected, the system automatically triggers failover to the standby database without requiring manual intervention, thereby eliminating service interruption time while maintaining operational control through automated decision-making.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

Automated monitoring and feedback mechanisms continuously assess the health of the operational database. When specific error conditions are detected through this feedback loop, the system automatically initiates failover procedures, eliminating the need for manual determination and reducing service interruption time while maintaining system control through predefined automated responses.

Inventive Principle:
Principle #23Feedback

4Adaptability or versatility

If application program access mechanism is changed, then DB access flexibility is improved, but application program complexity increases

Engineering Contradiction:
ImproveDB access flexibilityVSAvoidapplication program complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system introduces an intermediary access mechanism that abstracts the complexity of database failover from application programs. This intermediary layer automatically routes access requests to the appropriate database (operational or standby) based on system state, providing flexible database access while keeping application programs simple and unchanged.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS9189348B2High availability database management system and database management method using same
Publication Date: 2015.11.17 NAVER CORP
  • US9189348B2 patent drawing
  • US9189348B2 patent drawing
  • US9189348B2 patent drawing

AI summary

Provided is a method of managing a database (DB) using a high availability database management system (DBMS), which continuously provides a service when an error occurs in the DBMS. The DB management method in the high availability DBMS including a plurality of broker nodes and a plurality of server nodes may include an operation (a) to enable one of the plurality of broker nodes to access a main server node of the plurality of server nodes when a DB change request is received from an application server, and an operation (b) to enable the main server node to process the DB change request when the broker node succeeds in accessing the main server node, and to enable the broker node to access one of sub-server nodes so that the sub-server node processes the DB change request when the broker node fails to access the main server node due to an error in the main server node.