> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt

# `start`

## Description

Starts the synchronization between a source and destination cluster.

## Requirements

### State

To use the `start` endpoint, `mongosync` must be in the `IDLE` state.

### Permissions

The user specified in the `mongosync` connection string must have the required permissions on the source and destination clusters. Refer to [User Permissions](https://www.mongodb.com/docs/mongosync/current/reference/permissions.md#std-label-c2c-permissions-and-roles) to ensure that the user has the correct permissions to start the synchronization.

### Multiple `mongosync` Instances

Ensure that you use the configured `mongosync` user in the connection strings for the [`cluster0`](https://www.mongodb.com/docs/mongosync/current/reference/configuration.md#mongodb-setting-cluster0) or [`cluster1`](https://www.mongodb.com/docs/mongosync/current/reference/configuration.md#mongodb-setting-cluster1) settings when you start `mongosync`.

**Note:**

When you configure multiple `mongosync` instances to sync between sharded clusters, you must send identical API endpoint commands to each `mongosync` instance.

For more information, see [Start Multiple Mongosyncs.](https://www.mongodb.com/docs/mongosync/current/topologies/multiple-mongosyncs.md#std-label-c2c-sharded-start)

## Request

```http
POST /api/v1/start 

```

### Request Body Parameters

| Parameter | Type | Necessity | Description |
| --- | --- | --- | --- |
| `source` | string | Required | Name of the source cluster. |
| `destination` | string | Required | Name of the destination cluster. |
| `buildIndexes` | string | Optional | Configures index builds during sync. Supported Options: `afterDataCopy` (the default in source clusters running MongoDB 6.0 or later) causes `mongosync` to build indexes on the destination cluster after [collection copy](https://www.mongodb.com/docs/mongosync/current/about-mongosync.md#std-label-c2c-collection-copy). This includes indexes that exist on the source cluster at the point of initialization and indexes that are created during migration. This results in a faster migration for indexed databases.If the value of `buildIndexes` is `"afterDataCopy"` or `"excludeHashedAfterCopy"` and you set [createSupportingIndexes](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-mongosync-create-supporting-indexes-param) to `false` while migrating to a sharded cluster, `mongosync` creates a dummy index to support the shard key. `mongosync` attempts to drop this dummy index after `commit` is called. If no user-built indexes exist to support the shard key, dropping the dummy index will fail. Users are advised to drop the dummy index and create their own index after migration completes.IMPORTANT: This parameter is only supported for source clusters running MongoDB 6.0 or later.WARNING: With `afterDataCopy`, `mongosync` might fail to apply `Rename` [DDL](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-DDL--Data-Definition-Language-) events. For more details, see [Index Builds.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-build-indexes-limitations); `beforeDataCopy` (the default in source clusters running pre-6.0) causes `mongosync` to build indexes on the destination cluster during initialization. This includes indexes that exist on the source cluster at the point of initialization and indexes that are created during migration.; `excludeHashed` causes `mongosync` to skip building hashed indexes during sync. This can [improve performance](https://www.mongodb.com/docs/manual/tutorial/drop-a-hashed-shard-key-index/) for large collections.; `excludeHashedAfterCopy` causes `mongosync` to build non-hashed indexes on the destination cluster after [collection copy](https://www.mongodb.com/docs/mongosync/current/about-mongosync.md#std-label-c2c-collection-copy). `excludeHashedAfterCopy` also skips building hashed indexes. This results in a faster migration for indexed databases, due to both building indexes after initial data copy and skipping building hashed indexes.If the value of `buildIndexes` is `"afterDataCopy"` or `"excludeHashedAfterCopy"` and you set [createSupportingIndexes](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-mongosync-create-supporting-indexes-param) to `false` while migrating to a sharded cluster, `mongosync` creates a dummy index to support the shard key. `mongosync` attempts to drop this dummy index after `commit` is called. If no user-built indexes exist to support the shard key, dropping the dummy index will fail. Users are advised to drop the dummy index and create their own index after migration completes.IMPORTANT: This parameter is only supported for source clusters running MongoDB 6.0 or later.; `never` causes `mongosync` to skip building unnecessary indexes during sync. This can improve migration performance, especially with index heavy workloads.If you start sync with verification enabled and `buildIndexes` set to `never`, the migration will fail if `mongosync` finds a TTL collection on the source cluster. This can happen after you call the `/start` endpoint or much later, such as where a user creates a TTL index on the source cluster while a migration is in progress.To sync TTL collections without building indexes on the destination cluster, you must start sync with the [verifier disabled.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-disabled-verifier)WARNING: Do **not** manually build indexes on the destination cluster while `mongosync` is performing a migration.  Wait until the migration is fully committed.For more information on the indexes it does build, see [Required Indexes.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-required-indexes) `/start` returns an error when `buildIndexes` is set to `never` and `reversible` is set to `true`. If you call `/start` without specifying the `buildIndexes` option, `mongosync` builds indexes on the destination cluster. **New in version 1.3.0** |
| `detectRandomId` | boolean | Optional | When `true`, `mongosync` checks for random `_id` values in collections that are not [clustered](https://www.mongodb.com/docs/manual/core/clustered-collections.md#std-label-clustered-collections) or [capped](https://www.mongodb.com/docs/manual/core/capped-collections.md#std-label-manual-capped-collection), and are larger than 20 GiB (gibibytes). If `mongosync` determines that the collection uses random `_id` values, it copies the collection in natural order instead of the default `_id` order. This reduces the time `mongosync` takes to complete the [collection copy](https://www.mongodb.com/docs/mongosync/current/about-mongosync.md#std-label-c2c-collection-copy) phase. To explicitly specify collections that `mongosync` copies in natural order, see the [copyInNaturalOrder](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-copy-natural-order) option. By default, `detectRandomId` is `true`. WARNING: For collections that `mongosync` selects for natural scan, if migrations are interrupted, these copy operations must be redone entirely upon `mongosync` restart or resume. This can increase the time `mongosync` takes to complete the collection copy phase. |
| `includeNamespaces` | array | Optional | Filters the databases or collections to include in sync. If you configure a filter on a source cluster that has multiple databases, `mongosync` only syncs the databases specified in the filter definition. `mongosync` will not sync the other existing databases. If you want to modify the filter to add a newly created database, you have to [restart the filtered sync](https://www.mongodb.com/docs/mongosync/current/reference/collection-level-filtering.md#std-label-c2c-change-filter) from the beginning. For more details, see [Filtered Sync.](https://www.mongodb.com/docs/mongosync/current/reference/collection-level-filtering.md#std-label-c2c-filtered-sync) For current limitations, see [Filtered Sync.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-filtering-limitations) **New in version 1.1** |
| `excludeNamespaces` | array | Optional | Filters the databases or collections to exclude from sync. If you configure a filter on a source cluster that has multiple databases, `mongosync` only syncs the databases specified in the filter definition. `mongosync` will not sync the other existing databases. If you want to modify the filter to add a newly created database, you have to [restart the filtered sync](https://www.mongodb.com/docs/mongosync/current/reference/collection-level-filtering.md#std-label-c2c-change-filter) from the beginning. For more details, see [Filtered Sync.](https://www.mongodb.com/docs/mongosync/current/reference/collection-level-filtering.md#std-label-c2c-filtered-sync) For current limitations, see [Filtered Sync.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-filtering-limitations) **New in version 1.6** |
| `copyInNaturalOrder` | array of documents | Optional | Copies a list of databases and collections in their natural order to the destination cluster. The natural order is the order in which you previously inserted the documents into the database. You must pass in an array of documents that each represent a database and its collections. For a syntax example, see [Natural Scan Capability.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-natural-scan-capability) IMPORTANT: Only use the `copyInNaturalOrder` option for collections that explicitly set a random `_id` field and are larger than 30 GiB (gibibytes). Using this option for collections of size 30 GiB (gibibyte) or greater significantly reduces the time that the [collection copy](https://www.mongodb.com/docs/mongosync/current/about-mongosync.md#std-label-c2c-collection-copy) phase takes. WARNING: If you `/resume` a `mongosync` migration after a `/pause` or interruption that has the `copyInNaturalOrder` option enabled for collections greater than 500GB in size, the migration can take multiple hours to complete. The [detectRandomId](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-mongosync-detect-random-id) option uses a lower collection size threshold of 20 GiB because it rigorously checks that collections have a low degree of correlation between the `_id` vales and their insertion order. `copyInNaturalOrder` has a higher threshold of 30 GiB because users might be more relaxed in their selection of collections to copy in natural order. |
| `preExistingDestinationData` | boolean | Optional | IMPORTANT: This feature is currently in Public Preview. Please review the behavior and limitations in this section in order to use this feature in production environments. Default value is `false`. If set to `true`: `mongosync` allows pre-existing namespaces on the destination cluster.; You must specify a namespace filter by using one or both of the `includeNamespaces` and `excludeNamespaces` parameters in your request.; The destination cluster must not contain namespaces that conflict with the migrated namespaces.; If [embedded verification](https://www.mongodb.com/docs/mongosync/current/reference/verification/embedded.md#std-label-c2c-embedded-verifier) is enabled, the namespace filter must filter out any pre-existing collections or indexes on the destination cluster, even if they don't exist on the source cluster. Otherwise, embedded verification fails.; Ensure that you follow all directions in the [cutover process](https://www.mongodb.com/docs/mongosync/current/reference/cutover-process.md#std-label-c2c-cutover-process) to ensure that no unsafe writes occur on the source or destination cluster. `mongosync` does not enable write-blocking when you enable this feature, so you must manually ensure that these writes don't occur.; `mongosync` does not ensure that sufficient resources, such as disk space, compute, and oplog, exist on the destination cluster to accommodate the additional load of the migration. Monitor your destination cluster to ensure that it has sufficient resources.; `mongosync` does not migrate views when you use this feature. It ignores views on the source cluster during migration. You must migrate views separately after cutover.; The default [load level](https://www.mongodb.com/docs/mongosync/current/reference/configuration.md#std-label-mongosync-load-level) is changed from 3 to 2.; You can leave the balancer enabled for a sharded destination cluster during migration.; `mongosync` does not block writes on the source or destination cluster. To learn more, see [Write Blocking.](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior.md#std-label-c2c-write-blocking); `mongosync` does not allow reverse migration.; `mongosync` outputs the following log message in the beginning of migration:`ATTENTION! Data migration to a non-empty cluster is allowed
with the preExistingDestinationData set to true in the
request to start migration. This feature is currently in
preview. Please see https://www.mongodb.com/docs/cluster-to-cluster-sync/current/reference/api/start/
for important requirements and limitations.` See [Filtered Sync Limitations.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-filtering-limitations) |
| `reversible` | boolean | Optional | If set to `true`, enables the sync operation to be reversed. This option is not supported for the following configurations: Sync from a replica set to a sharded cluster; Sync sharded clusters that have different numbers of shards; Reversible sync when `buildIndexes` is set to `never`. IMPORTANT: Setting reversible to `true` is only supported for source clusters running MongoDB 6.0 or later. For more information, see the [reverse](https://www.mongodb.com/docs/mongosync/current/reference/api/reverse.md#std-label-c2c-api-reverse) endpoint. Default value is `false`. |
| `sharding` | document | Optional | Configures sync between a replica set and sharded cluster. Sync from a replica set to a sharded cluster requires this option. For more information, see [Sharding Parameters.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-api-start-sharding) **New in version 1.1** |
| `skipDiskSpaceCheck` | boolean | Optional | Disables the destination disk space pre-flight check. Default value is `false`. Set `skipDiskSpaceCheck` to `true` when the destination filesystem statistics do not accurately represent the storage available to the migration. For the full behavior of the check, see [Destination Disk Space.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-destination-disk-space) **New in version 1.22** |
| `verification` | Document | Optional | Configures the embedded verifier. For more information, see [Embedded Verifier.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-start-verifier) **New in version 1.9** |
| `verification.enabled` | Bool | Optional | Enables the embedded verifier. The verifier performs a series of verification checks on supported collections on the destination cluster to confirm that the migration was successful. If the verifier finds no errors, `mongosync` transitions to the `COMMITTED` state. If it does encounter errors, it fails the migration. The verifier is enabled by default. WARNING: The verifier does not check all collections or data. For details, see [Embedded Verifier.](https://www.mongodb.com/docs/mongosync/current/reference/limitations.md#std-label-c2c-verify-embedded-limitations) **New in version 1.9** |

### Sharding Parameters

**New in version 1.1**

To sync from a replica set to a sharded cluster, set the `sharding` option to shard collections on the destination cluster.

`mongosync` throws an error if the `sharding` option is not set when syncing from a replica set to a sharded cluster. `mongosync` also throws an error if the `sharding` option is set with any other configuration.

The `sharding` option has the following parameters:

| Parameter | Type | Description |
| --- | --- | --- |
| `createSupportingIndexes` | boolean | Optional. Sets whether sync creates a supporting index for the shard key, if none exists. The default is `false`. If the value of `buildIndexes` is `"afterDataCopy"` or `"excludeHashedAfterCopy"` and you set [createSupportingIndexes](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-mongosync-create-supporting-indexes-param) to `false` while migrating to a sharded cluster, `mongosync` creates a dummy index to support the shard key. `mongosync` attempts to drop this dummy index after `commit` is called. If no user-built indexes exist to support the shard key, dropping the dummy index will fail. Users are advised to drop the dummy index and create their own index after migration completes. If you set this parameter to `true` and set `buildIndexes` to `"excludeHashed"` or `"excludeHashedAfterCopy"`, then `mongosync` does not create supporting hashed indexes for hashed shard keys on the destination cluster. `mongosync` still builds non-hashed supporting indexes for non-hashed shard keys. For more information and limitations, see [Supporting Indexes.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-supporting-index-behavior) |
| `shardingEntries` | array of documents | Required. Sets the namespace and key of collections to shard during sync. Collections not included in this array sync to unsharded collections on the destination cluster. If set with an empty array, no collections are sharded. |
| `shardingEntries``.collection` | string | Sets the collection to shard. |
| `shardingEntries``.database` | string | Sets the database of the collection to shard. |
| `shardingEntries``.shardCollection` | document | Sets the shard key to generate on the destination cluster. |
| `shardingEntries``.shardCollection``.key` | array | Sets the fields to use for the shard key. For more information, see [Shard Keys.](https://www.mongodb.com/docs/manual/core/sharding-shard-key.md#std-label-shard-key) |

## Response

| Field | Type | Description |
| --- | --- | --- |
| `success` | boolean | When the request is successful, this value is `true`. |
| `error` | string | If an error occurred, indicates the name of the error. This field is omitted from the response when `success` is `true`. |
| `errorDescription` | string | Detailed description of the error that occurred. This field is omitted from the response when `success` is `true`. |

## Examples

### Start a Sync Job

The following example starts a sync job between the source cluster `cluster0` and the destination cluster `cluster1`.

Request:

```shell
curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1"
   } '

```

Response:

```json
{"success":true}

```

### Start a Reversible Sync Job

The following example starts a sync job between the source cluster `cluster0` and the destination cluster `cluster1`.

The `reversible` field allows the sync to be reversed. To reverse the sync direction, see: [reverse.](https://www.mongodb.com/docs/mongosync/current/reference/api/reverse.md#std-label-c2c-api-reverse)

Request:

```shell
curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "reversible": true
   } '

```

Response:

```json
{"success":true}

```

### Start a Filtered Sync Job

The following example starts a sync job between the source cluster `cluster0` and the destination cluster `cluster1`.

`cluster0` contains the `sales`, `marketing`, and `engineering` databases.

The `sales` database contains the `EMEA`, `APAC`, and `AMER` collections.

The `includeNamespaces` array in this example defines a filter on two of the databases, `sales` and `marketing`.

The `sales` database also filters on the `EMEA` and `APAC` collections.

```json
"includeNamespaces" : [
      {
          "database" : "sales",
          "collections": [ "EMEA", "APAC" ]
      },
      {
          "database" : "marketing"
      }
   ]

```

After you call the `/start` API with this filter in place, `mongosync`:

- Syncs all of the collections in the `marketing` database

- Filters out the `engineering` database

- Syncs the `EMEA` and `APAC` collections from the `sales` database

- Filters out the `AMER` collection

The `includeNamespaces` option creates a filter. To filter the sync, see: [Filtered Sync](https://www.mongodb.com/docs/mongosync/current/reference/collection-level-filtering.md#std-label-c2c-filtered-sync)

Request:

```shell
curl -X POST "http://localhost:27182/api/v1/start" --data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "includeNamespaces": [
         {
             "database": "sales",
             "collectionsRegex": {
                "pattern": "^accounts_.+$",
                "options": "i"
             }
         }, {
            "database": "marketing"
         }
      ]
   } '

```

Response:

```json
{"success":true}

```

### Start Sync from Replica Set to Sharded Cluster

The following example starts a sync job between the source replica set `cluster0` and the destination sharded cluster `cluster1`. The `key` array in this example defines the shard key `{"location": 1, "region": 1 }`.

Request:

```text
curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "sharding": {
         "createSupportingIndexes": true,
         "shardingEntries": [
            {
                "database": "accounts",
                "collection": "us_east",
                "shardCollection": {
                   "key": [
                      { "location": 1 },
                      { "region": 1 }
                   ]
                }
            }
         ]
      }
   } '

```

Response:

```json
{"success":true}

```

### Start with the Verifier Disabled

Starting in 1.9, the embedded verifier runs by default when you start a migration. If you need to disable it, set `verification.enabled` to `false`.

Request:

```text
curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "verification": {
         "enabled": false
      }
   } '

```

Response:

```json
{"success":true}

```

You should verify that a migration was successful before transferring your application load to the destination cluster. If you need to disable the verifier for any reason, use an alternative [method](https://www.mongodb.com/docs/mongosync/current/reference/verification.md#std-label-c2c-verification) to verify sync.

## Behavior

### Embedded Verifier

Starting in 1.9, `mongosync` provides an embedded verifier to determine whether data transfer from the source cluster to the destination was successful.

When enabled, the verifier performs a series of verification checks on the destination cluster. If any of these checks return an error, the verifier fails the migration. If all checks succeed, `mongosync` transitions to the `COMMITTED` state.

To disable the verifier, see [Start with the Verifier Disabled.](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-c2c-disabled-verifier)

The `/start` endpoint returns an error if you enable verification checks that are not supported by the source or destination cluster or if there is insufficient memory.

### State

If the `start` request is successful, `mongosync` enters the `RUNNING` state.

### Shard Replica Sets

Sync from a replica set to a sharded cluster requires the `sharding` option. This option configures how `mongosync` shards collections.

The `sharding.shardingEntries` array specifies the collections to shard. Collections that are not listed in this array replicate as unsharded.

For more information, see [Sharded Cluster Behavior.](https://www.mongodb.com/docs/mongosync/current/reference/mongosync-behavior.md#std-label-c2c-sharded-cluster-behavior)

### Supporting Indexes

`mongosync` syncs indexes from the source cluster to the destination cluster. When syncing from a replica set to a sharded cluster, `mongosync` may require an additional index to support the shard key, which may not exist on the source cluster.

`mongosync` can create supporting indexes for sharded collections during sync. This is done by setting the `sharding.createSupportingIndexes` option.

When `sharding.createSupportingIndexes` is `false` (the default):

- Each shard key you provide for the `sharding.shardingEntries` option must have an existing index on the source cluster.

- One of the indexes used for the shard key must have simple collation if the collection uses any other collation.

- To use a unique index in the shard key, you must specify its uniqueness when you create the index on the source cluster.

- Unique indexes on the source cluster that are incompatible with the requested shard key on the destination cluster, such as a unique index on the source that does not contain the requested shard key as a prefix on the destination, can cause `mongosync` to fail.

- If the value of `buildIndexes` is `"afterDataCopy"` or `"excludeHashedAfterCopy"` and you set [createSupportingIndexes](https://www.mongodb.com/docs/mongosync/current/reference/api/start.md#std-label-mongosync-create-supporting-indexes-param) to `false` while migrating to a sharded cluster, `mongosync` creates a dummy index to support the shard key. `mongosync` attempts to drop this dummy index after `commit` is called. If no user-built indexes exist to support the shard key, dropping the dummy index will fail. Users are advised to drop the dummy index and create their own index after migration completes.

When `sharding.createSupportingIndexes` is `true`:

- If the supporting indexes exist on the source cluster, `mongosync` syncs the indexes to the destination cluster and uses them as shard keys.

- If the supporting indexes don't exist, `mongosync` creates them on the destination cluster.

The `sharding.createSupportingIndexes` option affects all sharded collections.

### Rename During Sync

Collections listed in the `sharding.shardingEntries` array when synced from a replica set to a sharded cluster become sharded collections on the destination cluster.

Renaming a collection (such as with the [`renameCollection`](https://www.mongodb.com/docs/manual/reference/command/renameCollection.md#mongodb-dbcommand-dbcmd.renameCollection) command) on the source cluster after calling `start` but before `mongosync` begins to copy the collection can block the collection from sharding on the destination.

**Note:**

Renaming collections to use a different database while syncing from a replica set to a sharded cluster is not supported.

To check whether it is safe to rename collections, call the [`progress`](https://www.mongodb.com/docs/mongosync/current/reference/api/progress.md#std-label-c2c-api-progress) endpoint and check the value of the `collectionCopy.estimatedCopiedBytes` field in the return document.

- A value of 0 indicates that `mongosync` has not started to copy the collection.

  Renaming a collection at this point may result in an unsharded collection on the destination cluster, as the transition to copying can happen before the rename takes effect on the source.

- A value greater than 0 indicates that `mongosync` has started the copy. Renaming the collection from this point on does not block its sharding on the destination cluster, even in the event  of a crash.

### Required Indexes

When you call `/start` with the `buildIndexes` option set to `never`, `mongosync` skips building unnecessary indexes.

Indexes that are always built include:

- `mongosync` builds an index on the `_id` field of every collection it copies.

- `mongosync` builds dummy indexes for each sharded collection that does not have an index to support the shard key on the destination cluster. When `buildIndexes` is set to `never`, `mongosync` retains this index after commit.

### Endpoint Protection

`mongosync` does not protect the `start` endpoint.  However, by default the API binds to localhost only and does not accept calls from other sources. Additionally, the `start` call does not expose connection credentials or user data.

### Natural Scan Capability

When you call `/start` with the `copyInNaturalOrder` option, you must specify the databases and collections by using documents, such as in the following example.

Request:

```shell
curl -X POST "http://localhost:27182/api/v1/start" --data '
  {
    "source": "cluster0",
    "destination": "cluster1",
    "copyInNaturalOrder": [
      {
        "database": "sales",
        "collections": [
          "accounts",
          "orders"
        ]
      },
      {
        "database": "marketing",
        "collections": [
          "offers"
        ]
      }
    ]
  }'

```

Response:

```json
{"success":true}

```

WARNING: If you enable the migration for collections with non-random `_id` fields, the [collection copy](https://www.mongodb.com/docs/mongosync/current/about-mongosync.md#std-label-c2c-collection-copy) phase can take longer to complete when you specify `copyInNaturalOrder`.

You can use `copyInNaturalOrder` to copy all collections in multiple databases in their natural order, such as in the following example.

Request:

```shell
curl -X POST "http://localhost:27182/api/v1/start" --data '
  {
    "source": "cluster0",
    "destination": "cluster1",
    "copyInNaturalOrder": [
      {
        "database": "sales"
      },
      {
        "database": "marketing"
      }
    ]
  }'


```

Response:

```json
{"success":true}

```

You can use `copyInNaturalOrder` to copy **all** databases and their collections in their natural order.

Request:

```shell
curl -X POST "http://localhost:27182/api/v1/start" --data '
  {
    "source": "cluster0",
    "destination": "cluster1",
    "copyInNaturalOrder": [
      {
        "database": "."
      }
    ]
  }'

```

Response:

```json
{"success":true}

```