Hybrid Database Shadow Copy Migration Without Downtime

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems face challenges in scaling out to accommodate increasing data and workload demands without causing downtime, errors, and latency due to unpredictable database transformations over time, especially when migrating between databases with different schemas or architectures.

Innovation Solution

A hybrid database system operates two databases in parallel, allowing data records to be initially stored in a first database with real-time shadow copies in a second database, enabling policy-driven ownership transfer and deletion based on record-specific policies, thereby facilitating gradual migration without downtime.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a single database system is used to store all data, then device complexity is low, but scalability and reliability deteriorate when data quantity and workload increase

Engineering Contradiction:
Improvedatabase reliabilityVSAvoiddatabase architecture complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent divides the database into multiple independent instances (first database and second database) that can operate separately. Each database can be optimized for specific workloads or data types, allowing the system to scale reliability by adding more database instances rather than expanding a single complex database architecture.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system dynamically changes the operational parameters of different databases based on data characteristics and workload requirements. By selecting which database to write to based on data type, age, or other parameters, the system optimizes reliability without requiring a monolithic complex database architecture.

Inventive Principle:
Principle #35Parameter changes

2Quantity of substance

If database scale-up is performed by increasing server nodes, then storage capacity and bandwidth increase, but downtime and migration risk increase

Engineering Contradiction:
Improvedata storage capacityVSAvoidmigration downtime
Core Design Contradiction:
Quantity of substanceVSLoss of time

Solution Approach 1:

The patent implements preliminary action by maintaining multiple databases in advance with different capacities and configurations. When scaling is needed, the system can switch to a pre-configured database with higher capacity without performing complex in-place migration, thus avoiding downtime while increasing storage capacity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system uses database copying or cloning to create new database instances that mirror existing ones but with increased capacity. This allows seamless scaling by switching traffic to a copied database rather than migrating data within a single database instance, eliminating migration downtime.

Inventive Principle:
Principle #26Copying

3Reliability

If data is replicated to multiple databases, then reliability and redundancy improve, but data consistency and synchronization complexity worsen

Engineering Contradiction:
Improvedata redundancyVSAvoiddata synchronization complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies local quality by allowing each database to have different replication characteristics and data consistency requirements. Not all databases need to be synchronized in real-time; the system can optimize each database's replication strategy based on its specific needs, reducing overall synchronization complexity while maintaining necessary redundancy.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The system dynamically adjusts replication strategies based on current operational conditions. By making replication flexible and adaptive rather than rigid and uniform, the system maintains reliability through redundancy while avoiding the complexity of enforcing strict consistency across all replicated databases.

Inventive Principle:
Principle #15Dynamics

4Adaptability or versatility

If hybrid database architecture is implemented, then adaptability and scalability improve, but system complexity and configuration difficulty increase

Engineering Contradiction:
Improvedatabase adaptabilityVSAvoidhybrid architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements universality by creating a framework that can handle multiple database types and configurations through a common interface and control mechanism. This allows the hybrid architecture to adapt to different database needs without requiring separate complex management systems for each database type, thus reducing overall configuration difficulty.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS20250370985A1Hybrid database architecture for custom scale-out
Publication Date: 2025.12.04 MICROSOFT TECHNOLOGY LICENSING LLC
  • US20250370985A1 patent drawing
  • US20250370985A1 patent drawing
  • US20250370985A1 patent drawing

AI summary

A method of hybrid database operation includes receiving, at a hybrid database storage system, a write request for a data record; assigning ownership of the data record to a first database; writing a primary copy of the data record to the first database and a shadow copy of the data record to a second database; detecting changes to the primary copy of the data record made in the first database while the first database remains owner of the data record; propagating the changes to the shadow copy of the data record to the second database; transferring ownership of the data record from the first database to the second database in response to determining ownership transfer criteria are satisfied for the data record; and subsequent to transferring the ownership, directing updates to the data record to the second database without updating data in the first database.