[Yandex Cloud documentation](../../../../index.md) > [Yandex Data Transfer](../../../index.md) > [Step-by-step guides](../../index.md) > [Configuring endpoints](../index.md) > MongoDB/Yandex StoreDoc > Source

# Transferring data from a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) source endpoint


Yandex Data Transfer enables you to migrate data from a MongoDB database and implement various data transfer, processing, and transformation scenarios. To implement a transfer:

1. [Explore possible data transfer scenarios](#scenarios).
1. [Prepare the MongoDB](#prepare) database for the transfer.
1. [Set up a source endpoint](#endpoint-settings) in Yandex Data Transfer.
1. [Set up one of the supported data targets](#supported-targets).
1. [Create](../../transfer.md#create) a transfer and [start](../../transfer.md#activate) it.
1. [Perform the required operations with the database](#db-actions) and [see how the transfer is going](../../monitoring.md).
1. In case of any issues, [use ready-made solutions](#troubleshooting) to resolve them.

## Scenarios for transferring data from MongoDB/Yandex StoreDoc (Managed Service for MongoDB) {#scenarios}

1. Migration: Moving data from one storage to another. Migration often means migrating a database from obsolete local databases to managed cloud ones.

    * [Migrating a MongoDB cluster](../../../tutorials/storedoc.md)
    * [Migrating a Yandex StoreDoc (Managed Service for MongoDB) cluster from 4.4 to 6.0](../../../tutorials/storedoc-versions.md)

1. Uploading data to scalable Object Storage storage allows you to save on data storage and simplifies the exchange with contractors.

For a detailed description of possible Yandex Data Transfer scenarios, see [Tutorials](../../../tutorials/index.md).

## Preparing the source database {#prepare}

{% list tabs %}

- Yandex StoreDoc (Managed Service for MongoDB)


    1. Estimate the total number of databases for transfer and the total Yandex StoreDoc workload. If the workload on the databases exceeds 10,000 writes per second, create multiple endpoints and transfers. For more information, see [Transferring data from a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) source endpoint](mongodb.md).
    
    1. [Create a user](../../../../storedoc/operations/cluster-users.md#adduser) with the `readWrite` role for each source database to replicate. The `readWrite` role is required to enable the transfer to write data to the `__data_transfer.__dt_cluster_time` service collection.

- MongoDB
    
    1. Estimate the total number of databases for transfer and the total MongoDB workload. If the workload on the databases exceeds 10,000 writes per second, create multiple endpoints and transfers. For more information, see [Transferring data from a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) source endpoint](mongodb.md).
    
    1. If not planning to use [Cloud Interconnect](../../../../interconnect/concepts/index.md) or [VPN](https://en.wikipedia.org/wiki/Virtual_private_network) for connections to an external cluster, make such cluster accessible from the Internet from [IP addresses used by Data Transfer](../../../../overview/concepts/public-ips.md#virtual-private-cloud).
       
       For details on linking your network up with external resources, see [this concept](../../../concepts/network.md#source-external).
    
    1. Make sure the MongoDB version on the target is `4.0` or higher.
    
    1. Make sure the MongoDB cluster is configured so that it returns correctly resolving IP addresses or FQDNs (fully qualified domain names) in response to requests.
    
    1. [Configure access to the source cluster from Yandex Cloud](../../../concepts/network.md#source-external). To configure a source cluster for connections from the internet:
        
        1. In the configuration file, change `net.bindIp` from `127.0.0.1` to `0.0.0.0`:
        
            ```yaml
            # network interfaces
            net:
              port: 27017
              bindIp: 0.0.0.0
            ```
        
        1. Restart `mongod`:
        
            ```bash
            sudo systemctl restart mongod.service
            ```
    
    1. If the source cluster does not use replication, enable it:
        
        1. Add the replication settings to the `/etc/mongod.conf` configuration file:
        
            ```yaml
            replication:
              replSetName: <replica_set_name>
            ```
        
        1. Restart `mongod`:
        
            ```bash
            sudo systemctl restart mongod.service
            ```
        
        1. Connect to MongoDB and initialize the replica set with this command:
        
            ```javascript
            rs.initiate({
                _id: "<replica_set_name>",
                members: [{
                    _id: 0,
                    host: "<IP_address_Yandex_StoreDoc_listens_on>:<port>"
                }]
            });
            ```
    
    1. Create a user with the `readWrite` role for all the source databases to replicate:
    
        ```javascript
        use admin
        db.createUser({
            user: "<username>",
            pwd: "<password>",
            mechanisms: ["SCRAM-SHA-1"],
            roles: [
                {
                    db: "<source_database_1_name>",
                    role: "readWrite"
                },
                {
                    db: "<source_database_2_name>",
                    role: "readWrite"
                },
                ...
            ]
        });
        ```
    
       Once started, the transfer will connect to the source on behalf of this user. The `readWrite` role is required to enable the transfer to write data to the `__data_transfer.__dt_cluster_time` service collection.
    
       {% note info %}
    
       For MongoDB 3.6 or higher, you only need to assign the created user the `read` role for the databases to replicate.
    
       {% endnote %}
    
    1. When using MongoDB 3.6 or higher, to run the transfer, the user must have the read permission for the `local.oplog.rs` collection and the read and write permissions for the `__data_transfer.__dt_cluster_time` collection. To assign a user the `clusterAdmin` role granting these permissions, connect to MongoDB and run the following commands:
    
        ```js
        use admin;
        db.grantRolesToUser("<username>", ["clusterAdmin"]);
        ```
    
       To grant more granular permissions, you can assign the `clusterMonitor` role required for reading the `local.oplog.rs` collection and grant read and write access to the `__data_transfer.__dt_cluster_time` system collection.

{% endlist %}

## Configuring a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) source endpoint {#endpoint-settings}

Data Transfer supports transfers from MongoDB starting with version 3.6.

When [creating](../index.md#create) or [updating](../index.md#update) an endpoint, you can define:

* [Yandex StoreDoc cluster](#managed-service) connection or [custom installation](#on-premise) settings, including those based on Yandex Compute Cloud VMs. These are required parameters.
* [Additional parameters](#additional-settings).

### Yandex StoreDoc (Managed Service for MongoDB) cluster {#managed-service}


{% note warning %}

To create or edit an endpoint of a managed database, you will need the [`managed-mongodb.viewer`](../../../../storedoc/security/index.md#mmg-viewer) role or the primitive [`viewer`](../../../../iam/roles-reference.md#viewer) role for the folder the cluster of this managed database resides in.

{% endnote %}


Connection to the database with the cluster specified in Yandex Cloud.

{% list tabs group=instructions %}

- Management console {#console}

    * **Connection type**: Select a database connection option:
    
        * **Self-managed**: Allows you to specify connection settings manually.
    
            Select **Yandex StoreDoc cluster** as the installation type and configure these settings:
    
            * **Yandex StoreDoc cluster**: Select the cluster to connect to.
            * **Authentication source**: Specify the database name in the cluster.
            * **User**: Specify the username Data Transfer will use to connect to the database.
            * **Password**: Enter the user password for access to the database.
    
        * **Connection Manager**: Allows connecting to the cluster via [Yandex Connection Manager](../../../../metadata-hub/quickstart/connection-manager.md):
    
            * Select the folder with the Yandex StoreDoc cluster.
            * Select **Managed DB cluster** as the installation type and configure these settings:
    
                * **Cluster for Managed DB**: Select the cluster to connect to.
                * **Connection**: Select or create a Connection Manager connection.
                * **Authentication source**: Specify the database name in the cluster.
    
            {% note warning %}
            
            To use a connection from Connection Manager, the user must have [access permissions](../../../../metadata-hub/operations/connection-access.md) for this connection of `connection-manager.user` or higher.
            
            {% endnote %}
    
    * **Security groups**: Select the cloud network to host the endpoint and security groups for network traffic.
    
      Thus, you will be able to apply the specified security group rules to the VMs and clusters in the selected network without changing the settings of these VMs and clusters. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).

- CLI {#cli}

    * Endpoint type: `mongo-source`.

    * `--cluster-id`: ID of the cluster you need to connect to.
    * `--database`: Database name.
    * `--user`: Username that Data Transfer will use to connect to the database.
    * `--security-group`: Network traffic security groups whose rules apply to VMs and clusters without altering their configurations. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
    
    * To set a user password to access the database, use one of the parameters:
    
        * `--raw-password`: Password as text.
        * `--password-file`: The path to the password file.

- Terraform {#tf}

    * Endpoint type: `mongo_source`.

    * `connection.connection_options.mdb_cluster_id`: ID of cluster to connect to.
    * `subnet_id`: ID of the [subnet](../../../../vpc/concepts/network.md#subnet) the cluster is in. The transfer will use this subnet to access the cluster. If the ID is not specified, the cluster must be accessible from the internet.
      
      If the value in this field is specified for both endpoints, both subnets must be hosted in the same availability zone.
    * `security_groups`: [Security groups](../../../../vpc/concepts/security-groups.md) for network traffic.
      
      Security group rules apply to a transfer. They allow opening network access from the transfer VM to the cluster. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
      
      Security groups and the `subnet_id` subnet, if the latter is specified, must belong to the same network as the cluster.
      
      {% note info %}
      
      In Terraform, it is not required to specify a network for security groups.
      
      {% endnote %}
    * `auth_source`: Name of the cluster database.
    * `connection.connection_options.user`: Username that Data Transfer will use to connect to the database.
    * `connection.connection_options.password.raw`: Password in text form.

    Here is an example of the configuration file structure:

    
    ```hcl
    resource "yandex_datatransfer_endpoint" "<endpoint_name_in_Terraform>" {
      name = "<endpoint_name>"
      settings {
        mongo_source {
          security_groups = ["<list_of_security_group_IDs>"]
          subnet_id       = "<subnet_ID>"
          connection {
            connection_options {
              mdb_cluster_id = "<cluster_ID>"
              auth_source    = "<DB_name>"
              user           = "<username>"
              password {
                raw = "<user_password>"
              }
            }
          }
          <additional_endpoint_settings>
        }
      }
    }
    ```


    For more information, see [this Terraform provider guide](../../../../terraform/resources/datatransfer_endpoint.md).

- API {#api}

    * `securityGroups`: Network traffic security groups whose rules apply to VMs and clusters without altering their configurations. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
    * `mdbClusterId`: ID of the cluster you need to connect to.
    * `database`: Database name.
    * `user`: Username that Data Transfer will use to connect to the database.
    * `password.raw`: Database user password (in text form).

{% endlist %}

### Custom installation {#on-premise}

The settings are given for the OnPremise use case when all fields are filled in manually.

{% list tabs group=instructions %}

- Management console {#console}

    * **Connection type**: Select a database connection option:
    
        * **Self-managed**: Allows you to specify connection settings manually.
    
            Select **Custom installation** as the installation type and configure these settings:
    
            * **Hosts**: Specify the IPs or FQDNs of the hosts to connect to.
            * **Replica set**: Specify the name of the replica set.
    
            * **Port**: Set the number of the port that Data Transfer will use for the connection.
    
            * **CA certificate**: To encrypt the transmitted data, upload the [PEM certificate](../../../../storedoc/operations/connect/index.md#get-ssl-cert) or add its contents as text.
              
              {% note warning %}
              
              If no certificate is added, the transfer may [fail with an error](../../../troubleshooting/index.md#failed-to-connect).
              
              {% endnote %}
    
            * **Subnet ID**: Select or [create](../../../../vpc/operations/subnet-create.md) a subnet in the required [availability zone](../../../../overview/concepts/geo-scope.md). The transfer will use this subnet to access the database.
    
              If this field has a value specified for both endpoints, both subnets must be hosted in the same availability zone.
    
            * **Authentication source**: Specify the database name in the custom installation.
    
            * **User**: Specify the username Data Transfer will use to connect to the database.
    
            * **Password**: Enter the user password for access to the database.
    
        * **Connection Manager**: Allows connecting to the database via [Yandex Connection Manager](../../../../metadata-hub/quickstart/connection-manager.md):
    
            * Select the folder the Connection Manager connection was created in.
            * Select **Custom installation** as the installation type and configure these settings:
    
                * **Connection**: Select or create a Connection Manager connection.
    
                * **Replica set**: Specify the name of the replica set.
    
                * **Authentication source**: Specify the database name in the custom installation.
    
                * **Subnet ID**: Select or [create](../../../../vpc/operations/subnet-create.md) a subnet in the required [availability zone](../../../../overview/concepts/geo-scope.md). The transfer will use this subnet to access the database.
    
                  If this field has a value specified for both endpoints, both subnets must be hosted in the same availability zone.
    
            {% note warning %}
            
            To use a connection from Connection Manager, the user must have [access permissions](../../../../metadata-hub/operations/connection-access.md) for this connection of `connection-manager.user` or higher.
            
            {% endnote %}
    
    * **Security groups**: Select the cloud network to host the endpoint and security groups for network traffic.
    
      This will allow you to apply the specified security group rules to VMs and DBs in the selected network without reconfiguring these VMs and DBs. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).

- CLI {#cli}

    * Endpoint type: `mongo-source`.

    * `--host`: IP address or FQDN of the master host you want to connect to.
    * `--port`: Number of the port that Data Transfer will use for the connection.
    * `--ca-certificate`: CA certificate if the data to transfer must be encrypted to comply with PCI DSS requirements.
      
      {% note warning %}
      
      If no certificate is added, the transfer may [fail with an error](../../../troubleshooting/index.md#failed-to-connect).
      
      {% endnote %}
    * `--subnet-id`: ID of the subnet the host is in. The transfer will use that subnet to access the host.
    * `--database`: Database name.
    * `--user`: Username that Data Transfer will use to connect to the database.
    * `--security-group`: Network traffic security groups whose rules apply to VMs and clusters without altering their configurations. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
    
    * To set a user password to access the database, use one of the parameters:
    
        * `--raw-password`: Password as text.
        * `--password-file`: The path to the password file.

- Terraform {#tf}

    * Endpoint type: `mongo_source`.

    * `on_premise.port`: Port number that Data Transfer will use for connections.
    * `connection.connection_options.on_premise.tls_mode.enabled.ca_certificate`: CA certificate if the data to transfer must be encrypted, e.g., to comply with the PCI DSS requirements.
      
      {% note warning %}
      
      If no certificate is added, the transfer may [fail with an error](../../../troubleshooting/index.md#failed-to-connect).
      
      {% endnote %}
    * `security_groups`: [Security groups](../../../../vpc/concepts/security-groups.md) for network traffic.
      
      Security group rules apply to a transfer. They allow opening network access from the transfer VM to the database VM. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
      
      Security groups must belong to the same network as the `subnet_id` subnet, if the latter is specified.
      
      {% note info %}
      
      In Terraform, it is not required to specify a network for security groups.
      
      {% endnote %}
    * `subnet_id`: ID of the [subnet](../../../../vpc/concepts/network.md#subnet) the cluster is in. The transfer will use this subnet to access the cluster. If the ID is not specified, the cluster must be accessible from the internet.
      
      If the value in this field is specified for both endpoints, both subnets must be hosted in the same availability zone.
    * `connection.connection_options.on_premise.replica_set`: Specify the name of the replica set.
    * `connection.connection_options.on_premise.hosts`: Specify the IP addresses or FQDN of the hosts to connect to.
    * `auth_source`: Name of the cluster database.
    * `connection.connection_options.user`: Username that Data Transfer will use to connect to the database.
    * `connection.connection_options.password.raw`: Password in text form.

    Here is an example of the configuration file structure:

    
    ```hcl
    resource "yandex_datatransfer_endpoint" "<endpoint_name_in_Terraform>" {
      name = "<endpoint_name>"
      settings {
        mongo_source {
          security_groups = ["<list_of_security_group_IDs>"]
          subnet_id       = "<subnet_ID>"
          connection {
            connection_options {
              on_premise {
                hosts       = [ "list of replica set hosts" ]
                port        = "<port_for_connection>"
                replica_set = "<replica_set_name>"
                tls_mode {
                  enabled {
                    ca_certificate = "<certificate_in_PEM_format>"
                  }
                }
              }
              auth_source = "<DB_name>"
              user        = "<username>"
              password {
                raw = "<user_password>"
              }
            }
          }
          <additional_endpoint_settings>
        }
      }
    }
    ```


    For more information, see [this Terraform provider guide](../../../../terraform/resources/datatransfer_endpoint.md).

- API {#api}

    * `onPremise`: Database connection parameters:
        * `hosts` — IP address or FQDN of the master host to connect to.
        * `port`: The number of the port that Data Transfer will use for the connection.
        * `tlsMode`: Parameters for encrypting the data to transfer, if required, e.g., for compliance with the PCI DSS requirements.
            * `disabled`: Disabled.
            * `enabled`: Enabled.
                * `caCertificate`: CA certificate.
          
                  {% note warning %}
                  
                  If no certificate is added, the transfer may [fail with an error](../../../troubleshooting/index.md#failed-to-connect).
                  
                  {% endnote %}
        * `subnetId`: ID of the subnet the host is in. The transfer will use that subnet to access the host.
    * `securityGroups`: Network traffic security groups whose rules apply to VMs and clusters without altering their configurations. For more information, see [Networking in Yandex Data Transfer](../../../concepts/network.md).
    * `database`: Database name.
    * `user`: Username that Data Transfer will use to connect to the database.
    * `password.raw`: Database user password (in text form).

{% endlist %}

### Collection filter {#additional-settings}

{% list tabs group=instructions %}

- Management console {#console}

    * **Included collections**: Data is only transferred from listed collections. All collections are transferred by default.

        When you add new collections while editing an endpoint used in **Snapshot and increment** or **Replication** transfers with the **Replicating** status, the data history for these collections will not get uploaded. To add a collection with its historical data, use the **List of objects for transfer** field in the [transfer settings](../../transfer.md#update).

    * **Excluded collections**: Data is transferred from all collections except the specified ones.

    Included and excluded collection names must meet the ID naming rules in MongoDB. Escaping double quotes is not required.

- CLI {#cli}

    * `--include-collection`: Transfer data only from the listed collections. The values are specified in `<database_name>.<collection_name>` format. All collections are transferred by default.

        When you add new collections while editing an endpoint used in **Snapshot and increment** or **Replication** transfers with the **Replicating** status, the data history for these collections will not get uploaded. To add a collection with its historical data, use the **List of objects for transfer** field in the [transfer settings](../../transfer.md#update).

    * `--exclude-collection`: Transfer data from all collections except the specified ones. The values are specified in `<database_name>.<collection_name>` format.

    * `--prefer-secondary`: Set to `true` to use replicas (if there are any in the cluster) instead of the master host to read data.

- Terraform {#tf}

    * `collections`: Transfer data only from the listed collections. All collections are transferred by default.

        When you add new collections while editing an endpoint used in **Snapshot and increment** or **Replication** transfers with the **Replicating** status, the data history for these collections will not get uploaded. To add a collection with its historical data, use the **List of objects for transfer** field in the [transfer settings](../../transfer.md#update).

    * `excluded_collections`: Data is transferred from all collections except the specified ones.

    * `secondary_preferred_mode`: Set to `true` to use replicas (if there are any in the cluster) instead of the master host to read data.

- API {#api}

    * `collections`: Transfer data only from the listed collections. You need to specify the following for each collection:
      
      * `databaseName`: Database name
      * `collectionName`: Collection name
      
      All collections are transferred by default.

        When you add new collections while editing an endpoint used in **Snapshot and increment** or **Replication** transfers with the **Replicating** status, the data history for these collections will not get uploaded. To add a collection with its historical data, use the **List of objects for transfer** field in the [transfer settings](../../transfer.md#update).

    * `excludedCollections`: Transfer data from all collections except the specified ones. You need to specify the following for each collection:
      
      * `databaseName`: Database name
      * `collectionName`: Collection name

    * `secondaryPreferredMode`: Set to `true` to use replicas (if there are any in the cluster) instead of the master host to read data.

{% endlist %}

If a source workload is high (over 10,000 write transactions per second), we recommend that you select these settings to have no more than ten different databases at each endpoint. This will help avoid database connection errors while the transfer is ongoing.

{% note info %}

* If you use several endpoints, you need to create a separate transfer for each one.
* Transferring of `Time Series` collections is not supported, so you should exclude such collections.

{% endnote %}


## Configuring the data target {#supported-targets}

Configure one of the supported data targets:

* [Yandex Object Storage](../target/object-storage.md)
* [YTsaurus](yt.md)
* [Yandex StoreDoc (Managed Service for MongoDB)](../target/mongodb.md).

For a complete list of supported sources and targets in Yandex Data Transfer, see [Available transfers](../../../transfer-matrix.md).

After configuring the data source and target, [create and start the transfer](../../transfer.md#create).

## Operations with the database during transfer {#db-actions}

* For transfers with the **Copying** status, you cannot perform any actions reducing the origin's _operation log_ (oplog) time window. You should not add, delete, or reconfigure shards in any way during copying or perform any other actions resulting in a shorter operation log time window.

* In **Replicating** transfers, you may encounter an issue with key duplication when a sharded MongoDB cluster with a sharding index other than `_id` is the target. While a transfer is underway, we caution against creating clusters with sharding indexes other than `_id` on the target.

## Troubleshooting data transfer issues {#troubleshooting}

Known issues when using a MongoDB endpoint:

* [Collection key size exceeds 5 MB](#string-size).
* [Collection object size exceeds 16 MB](#object-size).
* [No tables found](#no-tables).
* [Error when transferring a sharded cluster](#sharded).
* [Error when transferring timeseries collections](#timeseries).
* [Unable to recognize an external cluster IP address or FQDN](#cluster-config-issue).
* [Error at the copying stage](#history-lost)
* [Source data cannot be sharded](#cannot-get-delimiters)
* [Transfer failure with the `cursor.Decode` error](#invalid-length)

For more troubleshooting tips, see [Troubleshooting](../../../troubleshooting/index.md).

### Collection key size exceeds 5 MB {#string-size}

Error message:

```text
Warn(replication): Usage of bulk objects in 'database <DB_name>'
breaks change event log, transfer is stopping.
Reason: (Location<position_number>) Tried to create string longer than 16MB.
```

If collection key size exceeds 5 MB, _**Replication**_ type transfers get interrupted due to MongoDB's internal user object size limits.

**Solution:** [exclude](mongodb.md) any collections that exceed MongoDB limits from the transfer and [reactivate](../../transfer.md#activate) it.

### Collection object size exceeds 16 MB {#object-size}

Error message:

```text
Warn(replication): Usage of bulk objects in 'collection '<DB_name>.<collection_name>''
breaks change event log, transfer is stopping.
Reason: (BSONObjectTooLarge) BSONObj size: <object_size> (<object_size_in_hex>) is invalid.
Size muse be between 0 and 16793600(16MB).
```

If collection object size exceeds 16 MB, _**Replication**_ type transfers get interrupted due to MongoDB's internal user object size limits.

**Solution:** [exclude](mongodb.md) any collections that exceed MongoDB limits from the transfer and [reactivate](../../transfer.md#activate) it.

### No tables found {#no-tables}

Error message:

```text
Unable to find any tables
```

An empty number of collections was extracted from the database. This error may occur if the user lacks permissions for the database used in the transfer.

**Solution**: Grant `readWrite` permissions for the database being trasferred to the user on whose behalf the transfer is connecting to the source.

### Error when transferring a sharded cluster {#sharded}

**Solution**: In the **Snapshot settings** → **Parallel snapshot settings** [transfer parameter](../../transfer.md#update), specify the number of [workers](../../../concepts/index.md#worker) equal to the number of collections being transferred.

### Error when transferring timeseries collections {#timeseries}

Error messages:

```text
Unable to find any tables
```

```text
Cannot execute mongo activate hook:
Failed in accordance with configuration:
some tables from include list are missing in the source database: [<collection_name>]
```

Transfers of `Time Series` collections are not supported.

**Solution:** [exclude](mongodb.md#additional-settings) any Time Series collections from the transfer and [reactivate](../../transfer.md#activate) it.

### Unable to recognize an external cluster IP address or FQDN {#cluster-config-issue}

The transfer fails with the error message:

```text
server selection error: server selection timeout, current topology: { Type: ReplicaSetNoPrimary, Servers: [{ Addr: <unresolved_FQDN>, Type: Unknown, Last error: connection() error occurred during connection handshake: dial tcp: lookup <unresolved_FQDN> on <IP_address>: no such host }, ] }"
```

The transfer error is due to the configuration of the MongoDB (Managed Service for MongoDB) cluster. For example, when unresolved internal names are used in shard descriptions.

**Solution**:

Make sure the MongoDB cluster is configured so that it returns correctly resolving IP addresses or FQDNs (fully qualified domain names) in response to requests.

### Error at data copying stage {#history-lost}

The _**Snapshot and increment**_ type transfer terminates with the following error at the copying stage:

```text
encountered non-recoverable resume token error. Sync cannot be resumed from this state and must be terminated and re-enabled to continue functioning: (ChangeStreamHistoryLost) Resume of change stream was not possible, as the resume point may no longer be in the oplog.
```

The `ChangeStreamHistoryLost` error occurs when the total copy time of the MongoDB (Managed Service for MongoDB) source cluster data exceeds the operation log (oplog) time window size. You can check the current time window size in the management console. See the **Oplog window** chart of the [cluster monitoring page](../../../../storedoc/operations/monitoring.md).


**Solution**:

* Increase the oplog size (5% of the cluster disk size by default). To increase the oplog size in a Yandex StoreDoc source cluster, contact [support](https://center.yandex.cloud/support). To change the oplog size in case of a custom source installation, see the relevant MongoDB guide.
* Enable [parallel data copying](../../../concepts/sharded.md) to speed up the copying stage.
* Limit the list of transferable objects in the [transfer settings](../../transfer.md#create).

Once that is done, [activate](../../transfer.md#activate) the transfer again.

### Source data cannot be sharded {#cannot-get-delimiters}

The transfer from a MongoDB/Yandex StoreDoc source fails with the following error message:

```text
ERROR: Unable to Activate
error: "failed to execute mongo activate hook: Snapshot loading failed: unable to shard upload tables: unable to shard upload (main worker) tables: unable to shard tables for operation ID: unable to split table, err: cannot get delimiters: there are two or more types of objects in the sharding index"
```

The `cannot get delimiters: there are two or more types of objects in the sharding index` error means that the source collection `id` field contains different data types, making the source unsuitable for sharding.

**Solution**:

In the **Snapshot settings** → **Parallel snapshot settings** [transfer settings](../../transfer.md#update-copy-repl), specify one worker and one stream to disable sharding.

Once that is done, [activate](../../transfer.md#activate) the transfer again.

### Transfer failure with the cursor.Decode error {#invalid-length}

Error message:

```text
cursor.Decode returned error: invalid length
```

This error may occur if you are using binary data types `unsigned_byte(2) Binary` and `unsigned_byte(3) UUID` marked as deprecated according to the [BSON specification](https://bsonspec.org/spec.html).

`unsigned_byte(2) Binary` use case example:

```text
Binary.createFromBase64('<string in Base64>', 2)
```

**Solution**: For the transfer to work correctly, use binary subtype 0 instead of subtype 2 and binary subtype 4 instead of subtype 3.

For example, after you replace the expression above with `Binary.createFromBase64('<string in Base64>', 0)`, the error occurs no more.