Database Connection Affinity and Failover Mechanism
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In database clustering environments, existing technologies face challenges in maintaining efficient transaction processing due to network latency caused by continuous rerouting of requests, which is particularly problematic for Online Transaction Processing (OLTP) databases that require fast response times and robust concurrency control.
Innovation Solution
The solution involves establishing a local connection for database transactions when possible, avoiding distributed connections unless a failure occurs, and using an affinity module to maintain local database affinity while a failover module ensures automated failover to a distributed connection when necessary, thus minimizing network latency and optimizing workload distribution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If continuous rerouting of requests is implemented to balance workload across compute nodes, then workload distribution is improved, but network latency increases
Solution Approach 1:
The system establishes local connections between client applications and databases on the same compute node before failures occur. This preliminary local connection setup avoids the need for continuous rerouting and network latency during normal operation, while still enabling failover when needed.
Solution Approach 2:
The connection strategy dynamically adapts based on system state: using local connections during normal operation for low latency, and automatically switching to distributed connections when failures are detected. This dynamic behavior resolves the contradiction by adjusting the connection approach according to actual system conditions.
2Productivity
If local connections are prioritized to reduce network latency, then transaction processing efficiency is improved, but fault tolerance may be compromised
Solution Approach 1:
The system prepares for potential failures by establishing both local and distributed connection capabilities in advance. When a local database fails, the failover module can immediately switch to a distributed connection to a database on a different compute node, providing fault tolerance without sacrificing normal transaction processing efficiency.
Solution Approach 2:
The failover module acts as an intermediary that monitors local database health and automatically switches to distributed connections when failures are detected. This intermediary mechanism ensures that local connections are used for efficiency during normal operation, while fault tolerance is maintained through automatic failover capability.
3Reliability
If distributed connections are used to ensure failover capability, then reliability is improved, but network latency increases
Solution Approach 1:
The system uses distributed connections partially - only when necessary for failover - rather than continuously. During normal operation, local connections are used to avoid network latency. Distributed connections are activated only to the extent needed for reliability, resolving the contradiction by applying the right connection type in the right circumstances.
Data Source
AI summary
A first compute node of a plurality of compute nodes of a database cluster may receive a request for a database transaction from a client application. The client application may be located within the first compute node. A first connection may be established, without regard to whether another compute node has a lighter workload than the first compute node, between the client application and a first database of the database cluster. The first connection may be a local connection, wherein the first database is located within the first compute node. The first compute node may detect that a failure associated with the first database has occurred. The first compute node may execute a failover operation to continue servicing the request for the data. The executing of a failover operation may include establishing a second connection between the client application and a second database of the database cluster.