Database Failure Management via Backend Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database management systems face performance issues due to long query processing times and failures in database objects, which can lead to adverse effects on database performance and require efficient methods to manage failures and recover data.
Innovation Solution
A method for database failure management that involves receiving backend or frontend failure information, verifying event types, determining processing methods based on event types, and processing events by storing data in physical storage or re-establishing connections with recovered backends or frontends.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If data is stored in a database backend, then data storage capacity is improved, but system reliability deteriorates when backend failure occurs
Solution Approach 1:
The patent segments the database system into multiple independent backends (first backend, second backend) that can operate independently. When one backend fails, the system can continue processing events using other backends, thus maintaining system reliability while preserving data storage capacity through distributed segmentation.
Solution Approach 2:
The patent implements a mechanism where failed backends are temporarily discarded from active service, and their processing responsibilities are recovered by other healthy backends. The system receives backend failure information, stops routing events to failed backends, and upon receiving recovery information, re-integrates the recovered backend into the system, thus maintaining reliability while preserving storage capacity.
2Adaptability or versatility
If the database processes queries using multiple execution plans, then query processing flexibility is improved, but processing time increases
Solution Approach 1:
The patent applies preliminary action by pre-determining backend availability status before processing events. The system receives backend failure information in advance and proactively adjusts the event processing plan by excluding failed backends, thus avoiding time-consuming runtime checks and rejections during actual event processing.
Solution Approach 2:
The patent implements dynamic event processing where the system continuously adapts the processing plan based on real-time backend status. The event processing is dynamically adjusted by verifying backend health status and routing events to available backends, providing flexibility to handle varying system conditions while optimizing processing time through adaptive routing.
3Measurement precision
If the system verifies backend status for each event, then event processing accuracy is improved, but system complexity increases
Solution Approach 1:
The patent uses copying by maintaining a simplified copy of backend status information (failure information and recovery information) that can be verified without complex real-time checks. Instead of implementing complex health monitoring mechanisms, the system verifies events by checking against these status copies, thus improving accuracy while minimizing added complexity.
Data Source
AI summary
Disclosed is a non-transitory computer readable medium storing a computer program. When the computer program is executed by one or more processors of a computing device, the computer program performs procedures for database failure management, and the procedures may include: receiving backend failure information for at least one backend of one or more backends; receiving an event from a client after receiving the backend failure information; verifying whether the event is an event corresponding to a failed backend; verifying a type of the event if the event is an event corresponding to a failed backend; determining a method of processing the event corresponding to the failed backend based on the type of event, while backend failure occurs; receiving recovery information about the failed backend; and processing an event received from the client after receiving the recovery information about the backend.