Hierarchical Database Replication with Dynamic Server Selection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
As the number of replicated database servers increases, maintaining their consistency with the master database becomes challenging due to excessive load on the master server and network bandwidth saturation, and current configurations are manual and static, making them vulnerable to failures and changes.
Innovation Solution
Implementing a system where database servers determine a randomized transaction metric based on received updates and select another server to request updates from if the metric exceeds a predetermined threshold, allowing for dynamic reconfiguration of communication paths to ensure timely and efficient data synchronization.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If all replicated slave database servers connect directly to the master database server, then data consistency is maintained, but the master database server experiences excessive load and network bandwidth saturation
Solution Approach 1:
The patent segments the replication hierarchy by introducing intermediate slave database servers that can receive updates from the master and relay them to other slaves. This creates a hierarchical structure where the master server only directly communicates with a subset of slaves, distributing the replication load across multiple levels rather than concentrating all communication at the master level.
Solution Approach 2:
The patent uses intermediate slave database servers as mediators in the replication process. These intermediate slaves receive database updates from the master server and forward them to other slave servers, acting as relays that reduce the direct communication burden on the master server while maintaining data consistency across the entire hierarchy.
2Power
If replicated slave database servers receive updates from other slave database servers, then the load on the master database server is reduced, but the configuration process becomes manual and static, making it vulnerable to failures
Solution Approach 1:
The patent implements a dynamic configuration mechanism where slave database servers can automatically adjust their parent database server assignments based on operational metrics. The system continuously monitors transaction metrics and allows slaves to dynamically change their replication parent, transforming the static manual configuration into an adaptive system that responds to changing conditions.
Solution Approach 2:
The patent incorporates feedback mechanisms where slave database servers monitor transaction metrics (such as update frequency, latency, and success rates) and use this information to make intelligent decisions about which parent database server to connect to. This feedback loop enables automatic adaptation to network failures and performance degradation without manual intervention.
3Reliability
If the number of replicated database servers increases, then data availability is improved, but keeping them synchronized becomes increasingly difficult
Solution Approach 1:
The patent segments the large replication group into hierarchical levels, where the master server directly manages a manageable number of intermediate slaves, which in turn manage subsets of leaf slaves. This segmentation reduces the synchronization complexity at each level, as no single server needs to maintain direct connections with all slaves in the system.
Solution Approach 2:
The patent implements preliminary action by having slave database servers pre-evaluate potential parent database servers based on transaction metrics before establishing connections. This proactive approach allows the system to anticipate and avoid problematic connections before they cause synchronization issues, reducing the overall complexity of maintaining consistency across the replication hierarchy.
Data Source
AI summary
Systems and methods for receiving a database update and organizing hierarchical databases are provided. A database server may receive a database update requested from another server. The database server may determine a transaction metric based on the received database update. The database server may select another database server to request database updates from based on comparing the transaction metric with a predetermined transaction threshold.