Tenant-Level Database Recovery via Temporary Instance Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional native multi-tenant database systems lack a tenant-level backup and recovery mechanism, requiring the full database instance to be recovered to restore data for a single tenant, which can disrupt other tenants and is inefficient.
Innovation Solution
Implementing a tenant-level recovery process that creates a temporary database instance, replays log files to a specific point in time, exports and truncates tenant data, and loads it back into the original instance, allowing for independent tenant data recovery without affecting other tenants.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If full database instance recovery is performed to restore a single tenant's data, then the tenant data can be recovered to a specific point in time, but other tenants' operations are disrupted and computing resources are wasted
Solution Approach 1:
The patent segments the database instance into tenant-specific components, enabling independent recovery of individual tenant data. The system identifies and isolates the specific tenant's data objects (tables, indexes, constraints) from the full database instance, allowing targeted recovery operations that affect only the affected tenant while leaving other tenants' operations uninterrupted.
Solution Approach 2:
The patent extracts the specific tenant's data from the full database instance backup. By identifying the tenant's data objects and separating them from the complete database backup, the system can apply recovery operations selectively to only the extracted tenant data, avoiding the need to recover and reapply the entire database instance backup.
2Reliability
If full database instance recovery is performed, then complete data consistency is achieved, but computing resources and time are consumed proportionally to the entire database size
Solution Approach 1:
The patent applies partial action by recovering only the necessary portion of the database (specific tenant data) rather than the entire database instance. The system identifies the minimal set of data objects required for the affected tenant and applies recovery operations only to those objects, significantly reducing computing resource consumption and recovery time while maintaining data consistency for the affected tenant.
3Reliability
If full database instance recovery is performed, then all tenant data is restored, but the recovery process is inefficient and costly for small tenants
Solution Approach 1:
The patent segments the recovery process into tenant-specific operations. By identifying and isolating the affected tenant's data objects within the database instance, the system can apply recovery operations selectively to only those objects, simplifying the overall recovery process and reducing the complexity associated with managing full instance recoveries for each tenant.
Solution Approach 2:
The patent implements self-service capabilities where the system automatically identifies the affected tenant's data objects and performs targeted recovery operations without requiring manual intervention for full instance recovery. The database management system autonomously determines the scope of recovery needed and executes the appropriate operations, reducing operational complexity.
Data Source
Figure 1
Figure 2A
Figure 2B
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.