Relational Database Replication via Transaction Log Snapshots
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current data replication methods in relational databases often result in significant performance reduction due to high latency caused by queuing write transactions during the replication process, as they require disruptive operations to ensure data consistency.
Innovation Solution
A computer-implemented method that associates a relational source database with a transaction log, allowing for asynchronous data replication by identifying a start position in the log, creating a copy of unmodified data, and subsequently applying missed transactions to ensure consistency, thereby enabling concurrent write operations during replication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If read lock is created on source data to ensure consistency during replication, then data consistency is improved, but write operation latency increases significantly
Solution Approach 1:
The system performs preliminary actions by creating a consistent snapshot of the source data before replication begins, and pre-identifies the set of committed transactions that occurred during the replication process. This allows the target database to be initialized with a consistent state and then updated with the identified transactions, eliminating the need for blocking read locks during the replication process.
Solution Approach 2:
The invention introduces an intermediary mechanism (snapshot and transaction log analysis) that mediates between the source and target databases. Instead of directly blocking write operations on the source database, the system captures a snapshot and analyzes transaction logs to identify committed transactions, allowing both source writes and replication to proceed concurrently without interference.
2Reliability
If disruptive operations are performed to ensure consistency at replication start, then data consistency is improved, but source database performance deteriorates
Solution Approach 1:
The invention extracts the consistency assurance mechanism from the source database operations. Instead of performing disruptive operations that affect source database performance, the system takes a snapshot of the source data and extracts the set of committed transactions through log analysis. This extraction allows consistency to be ensured without impacting source database performance, as the snapshot and transaction identification occur independently of source database write operations.
3Reliability
If write transactions are queued during replication, then data consistency is improved, but processing speed decreases
Solution Approach 1:
The invention enables continuous write operations on the source database during the replication process by using snapshot-based consistency. Write transactions are not queued but continue to execute at full speed, while the replication process independently captures the snapshot and identifies committed transactions from the transaction log. This maintains the continuity of useful write actions without interruption or queuing.
Data Source
AI summary
Embodiments are provided for replicating a relational source database associated with a transaction log of the relational source database. In operation, embodiments may perform receiving a request for replicating data of the relational source database to a relational target database and identifying a first start position within the transaction log. Upon having identified the first start position, embodiments may further perform waiting at least a time period for ensuring that each transaction currently executing on the relational source database at a moment of receiving said request has terminated at an end of said time period. After having waited said time period, embodiments may perform an asynchronously creating of a copy of data of the relational source database to produce a created copy. In turn, embodiments may perform writing the created copy to the relational target database and identifying a repair start position within the transaction log.