Sharded Database Cluster Synchronization with Parallel Replicators

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database replication technologies are inadequate for efficient cluster-to-cluster synchronization, particularly in large-scale shard clusters, due to issues like index inconsistencies, out-of-order replication, and challenges in maintaining consistency across geographically distributed or vendor-diverse clusters.

Innovation Solution

A system utilizing multiple replicators, each responsible for a subset of data, executes in parallel to replicate data efficiently while allowing temporary index violations and maintaining eventual consistency, with mechanisms to handle shard migrations and change streams to ensure data integrity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If multiple replicators are executed in parallel to improve replication speed, then productivity is improved, but index inconsistencies and data integrity issues occur

Engineering Contradiction:
Improvereplication speedVSAvoiddata consistency
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system segments the replication task by dividing the source cluster data into multiple subsets, with each replicator handling a specific subset. This segmentation enables parallel execution while maintaining control over data consistency through structured coordination mechanisms.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system implements feedback mechanisms where replicators report their progress and state to a coordination system, which monitors for index inconsistencies and coordinates resolution. This feedback loop enables the system to detect and correct consistency issues that arise during parallel replication.

Inventive Principle:
Principle #23Feedback

2Loss of time

If replicators are executed in parallel to reduce synchronization time, then loss of time is reduced, but index violations and out-of-order replication occur

Engineering Contradiction:
Improvesynchronization timeVSAvoidreplication accuracy
Core Design Contradiction:
Loss of timeVSManufacturing precision

Solution Approach 1:

The system performs preliminary actions by pre-coordinating replication plans and preparing coordination mechanisms before parallel replication begins. This includes setting up index violation handling protocols and out-of-order detection mechanisms in advance.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

An intermediary coordination system is introduced between parallel replicators and the destination cluster. This intermediary manages the conflicts and inconsistencies that arise from parallel replication, ensuring that index violations are resolved and out-of-order operations are corrected.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Device complexity

If existing replication techniques are used for cluster-to-cluster synchronization, then device complexity is reduced, but reliability and consistency cannot be maintained

Engineering Contradiction:
Improvesystem simplicityVSAvoidsynchronization reliability
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The replication system is designed with universal components that can handle multiple functions: data replication, index synchronization, consistency verification, and conflict resolution. This multi-functionality maintains reasonable system complexity while achieving high reliability through integrated solutions.

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

Data Source

PatentUS12423199B2Systems and methods for synchronizing between a source database cluster and a destination database cluster
Publication Date: 2025.09.23 MONGODB INC
  • US12423199B2 patent drawing
  • US12423199B2 patent drawing
  • US12423199B2 patent drawing

AI summary

In some embodiments, a database cluster to cluster synchronization system may include multiple replicators coupled to a source database cluster and a destination database cluster, where the source and destination cluster may be shard clusters. Each of the multiple replicators may correspond to a respective subset of the source database cluster and configured to monitor changes of data on the respective subset of the source database cluster and translate the changes of data to one or more database operations to be performed on the destination cluster. The changes of data on the source database may be contained in respective change streams associated with each of the replicators.