Azure Cosmos DB for MongoDB vCore migration extension for Azure Data Studio FAQ (preview)

Refer to the error displayed on the extension to see why the validation is failing. Typically the issue is an inability to connect to the MongoDB endpoint. The issue could also potentially be the user not having sufficient privileges on the connected server to run the assessment.

To run an assessment, the user connected to MongoDb should have readAnyDatabase and clusterMonitor roles assigned on the source instance.

Use grantRolesToUser to configure appropriate roles for the currently connected user.

The assessment uses the serverStatus command to perform the feature compatibility assessment. Since this command doesn't provide the details of database or collection names, the extension is unable to report the resource names.

For more granular assessment details, rerun the assessment providing the folder path containing the MongoDB profiler logs in the Log Folder Path field.

You can locate the log file at the following path: /var/log/mongodb/mongodb.log. If the log file isn't found, check the location in the MongoDB config file.

For more information, see MongoDB log messages.

To reduce resource utilization on the source during migration, the extension estimates the number of documents in each collection to be moved from the source to the target instead of retrieving the exact count.

Azure Cosmos DB for MongoDB vCore doesn't support time series, clustered, or capped collections. Thus, these types of collections are either missing or disabled in the collection mapping step.

Azure Cosmos DB for MongoDB vCore supports the creation of new views. However, the migration extension doesn't provide support for migrating existing views.

After the migration is finished, you can always recreate the views.

Azure Cosmos DB for MongoDB vCore doesn't compress data on disk. A typical rough estimate is to double the storage size consumed by the collections on the source MongoDB instance to estimate the storage in the target Azure Cosmos DB for MongoDB vCore account.

The following databases and collections are considered internal for MongoDB:

Since the internal databases and collections aren't required in Azure Cosmos DB for MongoDB vCore, the extension doesn't enable the migration of these databases.

Each migration task in Azure Database Migration Service provides two trains for migration. Each train migrates one collection at any point in time. Hence, two collections are typically migrated in parallel. Once the migration for a collection is completed, the next collection is automatically picked up. If you have many collections to migrate, create multiple migrations tasks. Each task should have a scoped number of collections to help make the migrations more efficient.

There are no limits on the number of databases and collections that can be included in a single migration. However, the selected collections are split into batches of 50 when creating the migration tasks on Azure Database Migration Service. For large quantities of collections, you see multiple migration tasks in the migrations list.

When you select multiple collections to migrate, the order in which the collections are migrated isn't configurable. If you wish to control the order of migration, migrate the collections in smaller batches based on your desired sequence. For best performance, avoid combining larger collections with smaller collections in a batch.

Add firewall exceptions to the Azure Cosmos DB for MongoDB vCore target account to accept connections from global Azure datacenters. To locate the relevant IP range information download JSON from global Azure IP address ranges and look for "AzureCloud.{Target Cosmos DB Account Region}" within the JSON file.

Configure the source MongoDB instance to allow connections from global Azure datacenters. To locate the relevant IP range information download JSON from global Azure IP address ranges and look for "AzureCloud.{Target Cosmos DB Account Region}" within the JSON file.

The database, collections, and indexes are created directly using commands from the local Azure Data Studio client. This functionality requires connectivity between the client running Azure Data Studio with both the source and target environments.

The data migration tasks are run on Azure Database Migration Service. The migration service is an Azure service instance that orchestrates and performs data movement activities. Once the data migration tasks are created, you aren't required to be connected to the source and target environments.

There are no limits on the number of migrations you can create simultaneously.

The extension doesn't support database and collection renaming during migration.

It's possible to create multiple migration jobs, each having a limited number of collections. This approach is a best practice to optimize the speed of migrations.

The initial part of the report has the key details of the assessment run including a summary of the source MongoDB environment. Details include source MongoDB version, license type and instance type. This part also contains a list of the databases and collections assessed, with their respective assessment summaries and migration readiness.

The findings are grouped into Critical, Warning and Informational categories. These categories help you prioritize the findings according to their importance.

The assessment checks include:

The extension stores errors, warnings, and other diagnostic logs in the default log directory:

• Windows - C:\Users\<username>\.dmamongo\logs\
• Linux - ~/.dmamongo/logs
• macOS - /Users/<username>/.dmamongo/logs

Related content

• Add Azure Data Studio extension
• Azure Cosmos DB for MongoDB vCore
• Azure Cosmos DB for MongoDB vCore migration options