Moving an existing CosmosDB database/collection to CosmosDB Serverless when using MongoDB

Introduction

If we go several years back, I already leveraged the instant scaling of CosmosDB… Recently a new plan has been introduced to cover this behavior, being the Consumption Based / Serverless option! For a new project I immediately started using this one, and I am very happy about it. Where I came to a point where I said to myself, let us migrate the other databases (where fit) to this option too. For today’s post, I will go into the differences I noticed… and hopefully save you some time looking up things. 😉 Though be aware that I have been leveraging the MongoDB API/endpoint.

Connection Strings

One of the first things I noticed is that the connection strings are a bit different. The following screenshot is of an existing (non-serverless) CosmosDB ;

Now let us take a look at the serverless variant… and we see that additional things are added to the connection string ;

Where the first part remains the same ; “mongodb://***@vmoptimizer-dev-func-be.mongo.cosmos.azure.com:10255/?ssl=true&replicaSet=globaldb”. And the following part has been added ; “&retrywrites=false&maxIdleTimeMS=120000&appName=@vmoptimizer-dev-func-be@”

Another thing I noticed was that the hostname also changed… Where it used to be “X.documents.azure.com”, it is now also showing the API ; “X.mongo.cosmos.azure.com”.

 

Retry Writes

As you might have noticed, the “retrywrites=false” has been part of the connection string. The issue I encountered is that some MongoDB tooling plain ignores that option in the connection string…

And I was prompted with the following error message ;

2021-04-08T08:05:07.9724888Z 2021-04-08T08:05:07.971+0000 connected to: mongodb://[**REDACTED**]@vmoptimizer-dev-func-be.mongo.cosmos.azure.com:***@vmoptimizer-dev-func-be@
2021-04-08T08:05:08.0091405Z 2021-04-08T08:05:08.008+0000 Failed: (BadValue) Retryable writes are not supported. Please disable retryable writes by specifying “retrywrites=false” in the connection string or an equivalent driver specific config.
2021-04-08T08:05:08.0092650Z 2021-04-08T08:05:08.008+0000 0 document(s) imported successfully. 0 document(s) failed to import.

Luckily a post on Stack Overflow showed me to some shared pain and the solution… 😉 Stating that the following option would need to be added to the command line ;

--writeConcern="{w:0}"

Which did fix the issue for me!

 

Closing Thoughts

I am a happy camper in moving to the serverless variant. It did came with some unexpected changes… Luckily they are easily fixable. Though be aware that you need to do some tweaks and tests before going full force!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.