Docs Menu
Docs Home
/
MongoDB Cluster-to-Cluster Sync
/

Cluster-to-Cluster Sync Beta Program

On this page

  • Get Started
  • Beta Features
  • Feature Compatibility Matrix

Starting in version 1.8.0, Cluster-to-Cluster Sync introduces the Cluster-to-Cluster Sync Beta Program. With mongosync beta, you can use experimental features with direct support and assistance from MongoDB.

Each mongosync release has a corresponding mongosync beta build that includes its own set of experimental features.

Note

Filing a support ticket does not guarantee access to the mongosync beta binaries.

To request access to the mongosync beta binaries, read the following disclaimer and file a ticket with support:

MongoDB restricts access to beta features via the beta build. Your use
of the beta is governed by the language specified in the Cloud
Subscription Agreement, Cloud Terms of Service, or other applicable
agreement between you and MongoDB with respect to your use of
mongosync.
You understand that features are available through the beta build, and
flags are not generally available. All use of beta builds is at your own
risk. Beta builds provide no stability guarantees; API, UI, options, and
behaviors may change or be removed any time. MongoDB will never issue a
Critical Advisory or notify about defects in beta builds.
You should follow feature usage guidance provided by Field and R&D
without deviation and should only use beta builds for one-time, human-
supervised migrations (e.g., not for continuous sync or automated
migrations). Beta capabilities are not intended for use to migrate
production workloads.

When you first run the mongosync beta binary, it will prompt you to accept the disclaimer.

Tip

See also:

mongosync beta 1.9 includes the following features:

Feature
Description
A->B->C Migrations

Starting in mongosync beta 1.8, you can perform A->B->C migrations. A->B->C migrations allow you to perform two consecutive migrations, where the destination cluster of the first migration acts as the source cluster for the second migration.

Starting in mongosync beta 1.8, you can selectively migrate documents based on specific conditions. To further limit which documents migrate to the destination cluster, you can combine document filtering and namespace filtering.

Starting in mongosync beta 1.8, use the destinationDataHandling option in the start request to define what happens if the destination cluster already has user data. Earlier mongosync versions return an error if the destination cluster has user data.

Starting in mongosync beta 1.8, you can remap database names during sync. This allows you to take data in one database on the source cluster and migrate it into a different database on the destination cluster.

Starting in mongosync beta 1.8, you can perform Many-to-One migrations. Many-to-One migrations allow you to sync multiple source clusters simultaneously with a destination cluster. For example, you can consolidate data from many small clusters into a central cluster.

Starting in mongosync beta 1.8, you can enable Oplog Rollover Resilience (ORR). With ORR, mongosync applies changes made on the source cluster to the destination cluster concurrently with initial sync. For source clusters with a high write rate, ORR significantly lowers the risk of oplog rollover during initial sync and reduces the need to restart the sync.

Pre-6.0 Server Version Support
In mongosync beta, you can perform migrations between clusters running MongoDB server versions older than 6.0. To see guidelines and restrictions for migrating between older server versions, you must have access to the mongosync beta binary.

Note

Mongosync reverse mode is not compatible with any beta features except Oplog Rollover Resilience.

The following table shows supported combinations of beta features:

Warning

Unsupported feature combinations do not have guardrails and can result in undefined behavior.

Many-to-One
A->B->C Migration
Document Filtering
Namespace Remapping
Oplog Rollover Resilience
Destination Data Handling
Pre-6.0 Version Support
Many-to-One

A->B->C Migration

[1]
Document Filtering

Namespace Remapping

Oplog Rollover Resilience

Destination Data Handling

Pre-6.0 Version Support

[1]

[1](1, 2) A->B->C migrations are compatible with pre-6.0 version support only if cluster A uses a server version older than 6.0. If cluster B uses a pre-6.0 cluster, the second migration (B->C) can start only after the first migration (A->B) is committed.

Back

Version Compatibility