Tenant-Level Database Recovery via Temporary Instance
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional native multi-tenant database systems lack a tenant-level backup mechanism and efficient data recovery processes, requiring full database instance recovery to restore tenant data, which can be costly and inefficient.
Innovation Solution
Implementing a process for tenant-level recovery within a native multi-tenant database instance, which involves creating a temporary database instance, restoring it to a specific point in time, exporting and recovering tenant data, and then removing the temporary instance, while ensuring data consistency and minimizing disruption.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If full database instance recovery is used to restore tenant data, then data recovery reliability is improved, but resource consumption and cost increase significantly
Solution Approach 1:
The patent segments the database instance into tenant-level recovery units. Instead of recovering the entire database instance, the system creates a temporary database instance and restores only the specific tenant's data to a previous point in time using backup information. This segmentation allows selective recovery of only the affected tenant's data, significantly reducing resource consumption while maintaining recovery reliability.
Solution Approach 2:
The patent uses copying by creating a temporary database instance that replicates the structure of the original database instance. This temporary instance is then used to restore and export tenant data without affecting the original running instance. The copying approach enables isolated tenant recovery while maintaining the continuity of other tenants' operations.
2Reliability
If full database instance recovery is performed, then tenant data can be restored, but disruption to other tenants and service continuity deteriorate
Solution Approach 1:
The patent segments the recovery operation to affect only the specific tenant being restored. By creating a temporary database instance and performing recovery operations there, the system isolates the disruption to a single tenant while leaving other tenants' data and operations unaffected. This maintains service continuity for the majority of the system.
Solution Approach 2:
The temporary database instance acts as an intermediary during the recovery process. It serves as a sandbox where tenant data can be restored and validated without impacting the original running database instance. Other tenants continue to access the original instance normally, while the temporary instance handles the recovery operations.
3Stability of the object's composition
If conventional backup mechanisms are used, then data consistency is maintained, but backup and recovery efficiency deteriorate
Solution Approach 1:
The patent implements preliminary action by maintaining backup information of the database instance at previous points in time. These backups are created in advance and stored for later use during recovery operations. When tenant recovery is needed, the system can immediately access these pre-created backups to restore data efficiently without needing to perform complex real-time recovery operations.
Solution Approach 2:
The patent creates a copy of the database instance structure in the temporary database instance, then selectively restores only the necessary tenant data from backup information. This copying approach maintains data consistency by restoring complete tenant data sets while improving efficiency by avoiding the need to copy or restore the entire database instance.
Data Source
AI summary
Systems and methods include reception of an instruction to recover a first database tenant of a first database instance to a first point in time, the first database tenant associated with first database artifacts of the first database instance, and the first database instance including two or more database tenants and, in response to the instruction, creation of a second database instance, selection of backup data of the first database instance based on the first point in time, execution of a recovery of the backup data on the second database instance, export of second database artifacts of the first database tenant from the second database instance to a storage, truncation of the first database artifacts from the first database instance, import of the second database artifacts from the storage to the first database instance, and deletion of the second database instance.