Shared Container Switchover for Low-Downtime Multi-Tenant Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-tenancy database systems face challenges in efficiently managing shared resources and tenant-specific data, leading to increased storage and maintenance costs, and require significant application modifications for data sharing and schema flexibility.
Innovation Solution
A method involving the installation of a new shared container in parallel with the current one, linking tenant containers to it, and deploying changed tenant content, while maintaining a unified view for applications, allowing seamless transition with minimal downtime and individual tenant upgrades.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single instance of software application serves multiple tenants with dedicated share including tenant-specific data and configuration, then each tenant gets isolated and secure data access, but storage and maintenance costs increase due to data duplication across tenants
Solution Approach 1:
The patent merges shared common data into a single shared container that is collectively accessed by multiple tenant containers, eliminating data duplication while maintaining tenant isolation through view mechanisms. This combining approach reduces storage requirements while preserving the reliability of tenant-specific data access.
Solution Approach 2:
The shared container serves multiple functions by providing common data to multiple tenants simultaneously, allowing a single data storage structure to fulfill the data needs of numerous tenants without requiring separate copies, thereby reducing overall storage consumption while maintaining universal access.
2Adaptability or versatility
If multi-tenancy system deploys new version by replacing shared container, then system gets updated with new features and fixes, but all tenants experience downtime and loss of service continuity
Solution Approach 1:
The patent creates a new shared container in advance with the updated version before the current shared container is removed. This preliminary preparation allows the system to switch to the pre-prepared new version without interruption, as the new container is already ready and configured before deployment begins.
Solution Approach 2:
The patent introduces a new shared container as an intermediary structure that coexists temporarily with the old shared container. This intermediary approach allows gradual transition and switching without forcing all tenants to stop service, as the new container can be activated once ready while the old one continues serving existing tenants.
3Adaptability or versatility
If multi-tenancy system allows schema flexibility and data sharing, then system becomes more versatile and adaptable to tenant needs, but application modifications are required which increases complexity
Solution Approach 1:
The patent introduces a new dimension of schema flexibility by allowing the shared container to contain data with different schemas that can be selectively accessed by different tenants through view mechanisms. This additional dimensional approach enables schema diversity without requiring modifications to the application layer, as tenants can access different schema versions through the same application interface.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The present disclosure involves systems, software, and computer implemented methods for exchanging shared containers and adapting tenants in database systems. One example method includes receiving a request to deploy a new version of a database system. A deployment package is received that includes new version data. A new shared container is installed in parallel to a current shared container. The new version is deployed to each of multiple tenant containers. Each of the tenant containers is individually linked to the new shared container, including dropping at least one view in each respective tenant container to shared content in the current shared container and adding at least one view in each respective tenant container to the updated shared content in the new shared container. Changed tenant content is deployed to each tenant container. The current shared container is dropped after deployment to each of the multiple tenant containers has completed.