Adaptive Cloning for Logical Database Replication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database management systems face challenges in achieving efficient disaster recovery due to time-consuming and resource-intensive processes that often result in data loss, especially when maintaining up-to-date database copies across multiple locations, and the downtime required for replication can be costly and problematic.
Innovation Solution
The implementation of an end-to-end solution for logical transactional replication in a shared-nothing clustered database management system using adaptive cloning, which allows for high availability by establishing logical replication between databases and dynamically managing clones to ensure data availability and load balancing, while refreshing stale clones without preserving user transaction boundaries.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the database is shutdown to copy data to remote site for disaster recovery, then a consistent image of the database is provided to the remote site, but database downtime occurs which is time consuming and resource intensive
Solution Approach 1:
The system performs preliminary actions by continuously maintaining updated copies of database data on multiple nodes before a disaster occurs. The standby node continuously receives and applies data changes from the active node, so when a failure occurs, the standby node is already prepared with the most recent data, eliminating the need to shut down the database for replication.
Solution Approach 2:
The patent implements continuous replication where data changes are continuously transmitted from the active node to standby nodes. This continuous useful action ensures that the standby node always has the latest data without interrupting database operations, resolving the contradiction between maintaining consistency and avoiding downtime.
2Reliability
If multiple redundant copies of data are maintained for high availability, then fault tolerance is improved, but system complexity and resource consumption increase
Solution Approach 1:
The patent segments the database into data segments distributed across multiple nodes, with each node maintaining a subset of data. This segmentation allows for fault tolerance while managing complexity by dividing the overall system into smaller, manageable units rather than requiring complete redundancy of the entire database.
Solution Approach 2:
Different nodes maintain different copies of data based on their specific roles and configurations. The standby node maintains copies of specific data segments relevant to disaster recovery scenarios, rather than maintaining identical copies of all data, thereby reducing unnecessary complexity and resource consumption while preserving fault tolerance for critical operations.
3Reliability
If clones are refreshed to maintain up-to-date copies, then data availability is improved, but transaction boundaries may not be preserved which complicates replication correctness
Solution Approach 1:
The system implements feedback mechanisms where the standby node continuously monitors data changes and applies them in the correct sequence. The replication process includes feedback loops that track transaction boundaries and ensure that data is replicated in the correct order, maintaining both availability and transactional integrity.
Solution Approach 2:
The patent employs dynamic clone management where the system can switch between different clones based on availability and performance conditions. The clone refresh process is dynamic, allowing the system to maintain up-to-date copies while adapting to changing transaction boundaries and data change patterns to preserve replication correctness.
Data Source
AI summary
Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.