Database Failover via Abstraction Layer and Replication Locks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Failover operations in replicated distributed database systems often result in data inconsistencies and prolonged downtime due to the need to completely transfer current data to a new cluster, leading to potential information loss and outdated or erroneous data access.
Innovation Solution
A method and system that block new access requests to the original database cluster, complete any ongoing requests, wait for data replication to a secondary cluster, and then allow access to the new cluster, utilizing a database abstraction layer and lock servers to manage the failover process and ensure access invariance.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If data is completely transferred from the original distributed database cluster to the new cluster during failover, then data consistency is improved, but failover time increases substantially
Solution Approach 1:
The patent applies preliminary action by continuously replicating data changes from the original distributed database cluster to the new cluster before the failover operation is initiated. This ongoing replication ensures that when failover occurs, the new cluster already contains most current data, eliminating the need for a complete data transfer after switching clusters. The replication process runs in advance, so when the failover trigger occurs, only minimal additional synchronization is needed, dramatically reducing failover time while maintaining data consistency.
2Ease of operation
If software processes are forced to abort and restart during failover, then access to the original cluster is stopped, but service disruption increases
Solution Approach 1:
The patent introduces an intermediary mechanism in the form of a database abstraction layer that sits between software processes and the distributed database cluster. This abstraction layer intercepts access requests and manages the failover process transparently. When failover is triggered, the abstraction layer redirects access to the new cluster without forcing software processes to abort or restart. The intermediary handles the cluster switching at a lower level, allowing applications to continue operating with minimal awareness of the underlying infrastructure change, thereby reducing service disruption.
3Loss of information
If data replication is ongoing during failover, then data freshness is improved, but risk of data loss during transition increases
Solution Approach 1:
The patent implements feedback mechanisms through lock servers that continuously monitor the replication status between the original and new distributed database clusters. These lock servers track which data changes have been successfully replicated and provide real-time feedback on replication progress. During failover, this feedback information is used to determine when it is safe to switch clusters - only after confirming that all necessary data changes have been replicated. This feedback-driven approach ensures data freshness while maintaining data integrity during the transition, as the system waits for replication confirmation before completing the failover.
Data Source
AI summary
Systems and methods are disclosed herein for performing a failover operation between a first distributed database cluster and a second distributed database cluster. In one aspect, the method includes blocking a plurality of software processes from making any new access requests to the first distributed database cluster and completing a current access request to the first distributed database cluster that was initiated by one of the plurality of software processes before the failover operation was initiated, waiting for data to replicate from the first distributed database cluster to the second distributed database cluster, wherein replicating includes any changes to the data from the current access request, and allowing the plurality of software processes to make the new access requests to the second distributed database cluster once the replicating has completed.