Database Cache Synchronization for Faster Disaster Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional data replication methods in computing environments, such as cloud environments, take too long and result in data loss due to daily full syncs, leading to inconsistent data states and increased computational load.
Innovation Solution
Implement a mechanism for live synchronization of memory caches across computing clusters using serialized sync messages, such as JSON objects, to update secondary systems with only changed data, reducing the need for full resets and minimizing data loss.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If daily full sync is performed between primary and secondary computing systems, then data consistency is maintained, but computational load increases and data loss occurs due to incomplete synchronization
Solution Approach 1:
The patent extracts only the changed data portions from the complete database and transmits them to the secondary computing system, rather than performing full database synchronization. This is achieved by identifying and logging only the modified records, which significantly reduces computational load while maintaining data consistency.
Solution Approach 2:
The database synchronization process is segmented into identifying changed portions, logging those changes, and transmitting only the necessary updates. This segmentation allows the system to avoid processing entire databases and instead focus only on modified segments, reducing overall computational requirements.
2Speed
If cache memory is used to store database portions for faster access, then access speed improves, but data loss risk increases during system failures
Solution Approach 1:
The patent performs preliminary actions by logging database changes to persistent storage before they are fully committed to cache memory. This ensures that even if cache data is lost during a system failure, the changes have already been recorded and can be recovered, thus reducing data loss risk while maintaining fast cache access.
Solution Approach 2:
The patent introduces a change log as an intermediary between the database and cache memory. This intermediary layer records all changes persistently, serving as a safety mechanism that protects against data loss while allowing the cache to operate at high speed for normal access operations.
3Reliability
If complete database copies are synchronized to secondary systems, then disaster recovery capability is improved, but network bandwidth consumption and synchronization time increase
Solution Approach 1:
The patent extracts only the essential change information from the complete database and transmits this minimized data set to secondary systems for disaster recovery purposes. This extraction approach maintains the ability to recover databases while dramatically reducing network bandwidth consumption and synchronization time compared to copying entire databases.
Solution Approach 2:
The patent applies partial action by transmitting only the necessary portion of database changes (the minimal required for recovery) rather than complete database copies. This partial synchronization approach provides sufficient disaster recovery capability while minimizing time and bandwidth resources consumed.
Data Source
AI summary
This disclosure describes systems, software, and computer implemented methods for synchronizing between a primary and a secondary computing system, including receiving instructions to perform a change to a primary computing system database; performing the change to the database; logging the change in a database log; receiving instructions to change the portion of the database stored in the cache memory; performing a change to a registry based on the change of the portion of the database; generating a sync message by: encoding the change to the registry in a message with an identifier of the registry changed; obtaining a log indicating previous database changes logged in the database change log since a prior sync message was sent; appending the previous database changes since the prior sync message was sent to the message; and encoding the sync message as an object.