Two-Phase Backup for Distributed NoSQL Database Clusters
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing backup and restore technologies for distributed NoSQL databases face challenges in achieving cluster consistency without inter-node communication and quiescing database applications, especially in handling data corruption, accidental deletions, and catastrophic failures, while also optimizing storage efficiency.
Innovation Solution
The proposed solution involves a two-phase backup process for a master-slave NoSQL database cluster, where Phase 1 captures crash-consistent backups without quiescing the database and Phase 2 transforms these backups into cluster-consistent state through background processing, eliminating the need for inter-node communication and optimizing storage usage by deleting Phase 1 snapshots.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional backup methods are used for distributed NoSQL databases, then backup simplicity is maintained, but cluster consistency cannot be achieved without inter-node communication and quiescing database applications
Solution Approach 1:
The backup process is divided into two distinct phases: Phase 1 captures crash-consistent backups from all nodes independently without inter-node communication, and Phase 2 performs background processing to transform these backups into cluster-consistent state. This segmentation allows each phase to have a specific, simplified function while achieving the overall goal of cluster consistency.
Solution Approach 2:
Phase 1 performs preliminary backup actions by capturing crash-consistent backups from all nodes before any consistency transformation is needed. This preliminary capture of data states enables Phase 2 to focus solely on the consistency transformation without needing to coordinate complex inter-node operations during the actual backup.
2Productivity
If crash-consistent backups are captured without quiescing the database, then database availability is maintained, but data consistency across the cluster is compromised
Solution Approach 1:
The database continues to operate and accept writes during Phase 1 backup operations, maintaining continuity of useful action. The backup process does not interrupt database availability, and Phase 2 performs consistency transformation in the background without requiring database quiescing, thus preserving continuous operation.
Solution Approach 2:
Phase 2 acts as an intermediary processing step that transforms the crash-consistent backups from Phase 1 into cluster-consistent backups. This intermediary phase reconciles the inconsistency introduced by capturing backups without quiescing, using background processing to achieve consistency without interrupting database operations.
3Reliability
If Phase 1 snapshots are retained for disaster recovery, then restore capability is ensured, but storage space consumption increases
Solution Approach 1:
Phase 1 snapshots are discarded after Phase 2 completes the consistency transformation and creates the final cluster-consistent backups. The essential data is preserved in the Phase 2 backups, allowing Phase 1 snapshots to be safely deleted to free up storage space while maintaining disaster recovery capability through the Phase 2 backups.
Solution Approach 2:
The backup data undergoes a transformation in its state parameters from crash-consistent (Phase 1) to cluster-consistent (Phase 2). This parameter change enables the data to be stored in a more efficient and reliable format that maintains restore capability while allowing optimization of storage resource usage by eliminating redundant Phase 1 snapshots.
Data Source
AI summary
Methods and systems for a distributed database cluster are provided. One method for the distributed database cluster having a plurality of logical partitions, where each partition is used to store a plurality of replicas for a database, and each of the plurality of replicas are managed by one of a plurality of nodes includes preventing any topology change in the distributed database cluster; capturing a topology of the distributed database cluster prior to a first backup phase of a backup operation; generating a snapshot of all logical objects used by all active nodes to store the plurality of replicas of the database; initiating a second phase of the backup operation at a recovery node using the backup topology metadata after the first phase of the backup operation; and cloning snapshots of the logical objects from the first phase of the backup operation.