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

# Transferring data to a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) target endpoint


Yandex Data Transfer enables you to migrate data to a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) database and implement various data transfer, processing, and transformation scenarios. To implement a transfer:

1. [Explore possible data transfer scenarios](#scenarios).
1. [Configure one of the supported data sources](#supported-sources).
1. [Prepare your MongoDB/Yandex StoreDoc (Managed Service for MongoDB) database](#prepare) for the transfer.
1. [Configure the target endpoint](#endpoint-settings) in Yandex Data Transfer.
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 to 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. Data delivery is a process of delivering arbitrary data to target storage. It includes data retrieval from a queue and its deserialization with subsequent transformation to target storage format.
    
    * [Delivering data from Apache Kafka® to Yandex StoreDoc (Managed Service for MongoDB)](../../../tutorials/mkf-to-mmg.md)

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

## Configuring the data source {#supported-sources}

Configure one of the supported data sources:

* [MongoDB/Yandex StoreDoc](../source/mongodb.md)
* [Airbyte®](../../../transfer-matrix.md#airbyte)
* [YDS](../source/data-streams.md)
* [Apache Kafka®](../source/kafka.md)

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

## Preparing the target database {#prepare}

{% list tabs %}

- Yandex StoreDoc (Managed Service for MongoDB)
    
    1. [Create a database](../../../../storedoc/operations/databases.md#add-db).
    1. [Create a user](../../../../storedoc/operations/cluster-users.md#adduser) with the [`readWrite`](../../../../storedoc/concepts/users-and-roles.md#readWrite) role for the new database.
    1. To shard the migrated collections in the Yandex StoreDoc target cluster:
        1. Use [this guide](../../../../storedoc/tutorials/sharding.md) to create and configure empty sharded collections in the target database.
        
           Data Transfer does not automatically shard the migrated collections. Sharding large collections may take a long time and slow down the transfer.
        
        1. If sharding uses any key other than `_id` (default), [assign](../../../../storedoc/operations/cluster-users.md#updateuser) the `mdbShardingManager` role to the user.
        
        1. When [creating a target endpoint](mongodb.md), select `DISABLED` or `TRUNCATE` as your cleanup policy.
        
           Selecting the `DROP` policy will result in the service deleting all the data from the target database, including sharded collections, and replacing them with new unsharded ones when a transfer is activated.


- MongoDB
    
    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 not lower than that on the source.
    
    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 the target cluster to allow 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 target 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. Connect to the cluster and create a target database:
    
        ```javascript
        use <database_name>
        ```
    
    1. Create a user with the `readWrite` role for the target database:
    
        ```javascript
        use admin;
        db.createUser({
            user: "<username>",
            pwd: "<password>",
            mechanisms: ["SCRAM-SHA-1"],
            roles: [
                {
                    db: "<target_database_name>",
                    role: "readWrite"
                }
            ]
        });
        ```
    
       Once started, the transfer will connect to the target on behalf of this user.
    
    1. To shard the migrated collections in the target cluster:
        
        1. Set up a database and populate it with empty collections with the same names as those in the source.
        
           Data Transfer does not automatically shard the migrated collections. Sharding large collections may take a long time and slow down the transfer.
        
        1. Enable target database sharding:
        
            ```javascript
            sh.enableSharding("<target_database_name>")
            ```
        
        1. Shard every collection based on its namespace:
        
            ```javascript
            sh.shardCollection("<target_database_name>.<collection_name>", { <field_name>: <1|"hashed">, ... });
            ```
        
        
        1. To make sure that sharding is set up and enabled, get a list of available shards:
        
            ```javascript
            sh.status()
            ```
        
        1. If sharding uses any key other than `_id` (default), assign the `clusterManager` system role to the user Data Transfer will use for connection to the target cluster:
        
            ```javascript
            use admin;
            db.grantRolesToUser("<username>", ["clusterManager"]);
            ```
        
        1. When [creating a target endpoint](mongodb.md), select `DISABLED` or `TRUNCATE` as your cleanup policy.
        
           Selecting the `DROP` policy will result in the service deleting all the data from the target database, including sharded collections, and replacing them with new unsharded ones when a transfer is activated.


{% endlist %}

## Configuring a MongoDB/Yandex StoreDoc (Managed Service for MongoDB) target 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-target`.

    * `--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_target`.

    * `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_target {
          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}

Connection to the database with explicitly specified network addresses and ports.

{% 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-target`.

    * `--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_target`.

    * `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_target {
          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 %}

### Additional settings {#additional-settings}

{% list tabs group=instructions %}

- Management console {#console}

    * **Database**: Enter the database name. If you do not specify any name, the source database name will be used.

    * **Cleanup policy**: Select a way to clean up data in the target database before the transfer:
      
      * `Don't cleanup`: Select this option if you are only going to do replication without copying data.
      
      * `Drop`: Completely delete tables included in the transfer (used by default).
      
         Use this option so that the latest version of the table schema is always transferred to the target database from the source whenever the transfer is activated.
      
      * `Truncate`: Delete only the data from the tables included in the transfer but keep the schema.
      
         Use this option if the schema in the target database differs from the one that would have been transferred from the source during the transfer.

- CLI {#cli}

    `--target-database`: Specify the database name if you want to create collections in a database that is different from the source database.

- Terraform {#tf}

    * `database`: Specify the database name if you want to create collections in a database that is different from the source database.

    * `cleanup_policy`: Select a way to clean up data in the target database before the transfer:
      
      * `DISABLED`: Do not clean up (default).
      
         Select this option if only replication without copying data is performed.
      
      * `DROP`: Completely delete the collections included in the transfer.
      
         Use this option so that the latest collection version is always transferred to the target database from the source whenever the transfer is activated.
      
      * `TRUNCATE`: Delete only the data from the collections included in the transfer but keep the collections.
      
         Use this option if the structure of collections in the target database differs from the one that would have been transferred from the source during the transfer.

- API {#api}

    * `database`: Specify the database name if you want to create collections in a database that is different from the source database.

    * `cleanupPolicy`: Select a way to clean up data in the target database before the transfer:
      
      * `DISABLED`: Do not clean up (default).
      
         Select this option if only replication without copying data is performed.
      
      * `DROP`: Completely delete the collections included in the transfer.
      
         Use this option so that the latest collection version is always transferred to the target database from the source whenever the transfer is activated.
      
      * `TRUNCATE`: Delete only the data from the collections included in the transfer but keep the collections.
      
         Use this option if the structure of collections in the target database differs from the one that would have been transferred from the source during the transfer.

{% endlist %}

{% note warning %}

By default, Data Transfer transfers collections without sharding. If you are transferring data to a sharded target cluster and want your collections to be sharded:

1. [Prepare the target cluster](../../prepare.md#target-mg) to shard the collections.
1. Select `DISABLED` or `TRUNCATE` for cleanup policy.

Selecting the `DROP` policy will cause the service to delete all the data, including sharded collections, from the target database and replace them with new non-sharded ones when activating a transfer.

{% endnote %}

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).

For the full list of recommendations, 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](../source/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](../source/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](../source/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.