Database Proxy GTID Segmentation for Heterogeneous Sync
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing data synchronization methods for heterogeneous database systems fail to handle differing response results from distributed and standalone databases, potentially blocking transaction requests from clients.
Innovation Solution
A data synchronization method involving a proxy, Global Transaction Manager (GTM), and synchronization module to manage Global Transaction IDs (GTIDs), ensuring consistent transaction processing and one-way synchronization between distributed and standalone databases.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a Proxy is used to receive transaction data and rewrite it into structured languages for distributed and standalone databases, then data synchronization between heterogeneous databases is achieved, but the system cannot handle differing response results from the databases and may block transaction requests
Solution Approach 1:
The patent segments the transaction processing into two independent phases: write phase (client → distributed database via Proxy) and commit phase (standalone database synchronization). The Proxy only handles the write phase, while the commit phase independently synchronizes to the standalone database using GTIDs. This segmentation allows different response results to be handled separately without blocking the entire transaction.
Solution Approach 2:
The patent introduces GTM (Global Transaction Manager) and GTIDs (Global Transaction IDs) as intermediaries to manage transaction coordination between distributed and standalone databases. The GTM tracks GTIDs and manages the two-phase commit process, acting as a mediator that resolves response inconsistencies without requiring the Proxy to handle complex error reconciliation.
2Reliability
If the Proxy rewrites transaction data into structured languages for both distributed and standalone databases, then data synchronization is achieved, but the Proxy becomes a single point of failure when databases feedback different responses
Solution Approach 1:
The patent divides the synchronization process into two independent operations: (1) Proxy rewrites and sends structured language to distributed database, (2) GTM independently synchronizes to standalone database using GTIDs. This segmentation removes the Proxy as the single point of failure for handling both databases, as the standalone database synchronization is now independently managed.
Solution Approach 2:
The standalone database synchronization process becomes self-service through the GTM, which automatically tracks GTIDs and performs synchronization without requiring Proxy intervention for error handling. The system uses GTIDs to automatically identify and synchronize uncommitted transactions, reducing operational complexity.
3Reliability
If the Proxy handles both distributed and standalone database communications, then data synchronization is achieved, but transaction requests may be blocked when response results differ
Solution Approach 1:
The patent segments transaction handling so that the Proxy only processes the write phase to the distributed database, while the commit phase to the standalone database is handled independently by the GTM. This segmentation allows parallel processing of different transaction phases, preventing blocking and improving throughput while maintaining consistency through GTID tracking.
Solution Approach 2:
The patent implements preliminary action by having the Proxy immediately rewrite and send structured language to the distributed database upon receiving transaction data, without waiting for standalone database confirmation. The GTM then independently performs the commit phase, allowing transactions to proceed without blocking while ensuring eventual consistency through GTID-based tracking.
Data Source
Figure 1
Figure 2
Figure 3~4
AI summary
A data synchronization method and device for databases, and a storage medium are disclosed. The method includes: in the case where transaction response results fed back by multiple data nodes are all successful, receiving (S109) transaction commit request messages sent by a client, and writing (S110) a global transaction ID into a transaction processing list; sending (S111) the transaction commit request messages to the multiple data nodes; receiving (S112) transaction commit results fed back by the multiple data nodes; and in the case where the transaction commit results fed back by the multiple data nodes are all successful, applying (S114) to a global transaction manager to release the global transaction ID.