Guidelines for setting up a production instance


I apologise if this isn’t the right category. I am working on a project for a small business where i’m looking to migrate their data from MySQL over to Mongo as part of a rebuild of their services. I do feel for the most part mongo actually will be better suited than their MySQL instance especially for some of the aggregations and reporting.

I’m quite new to mongo, although I do have a fair amount of experience as an engineer querying/aggregating data but have no experience from the sysadmin side of things.

I’m mostly looking for advice and possibly documentation in order to correctly configure and set-up mongoDB for a production environment – i’m nervous about moving their data over to mongo and having problems or loss of data, and would like to prepare myself as best i can to migrate.

I wanted to run mongo in docker and mount the storage as a volume which I can then back-up with rsync to an external storage periodically. Would this be viable?


1 Like

Hello @Ashley_Meadows well come to the community!

It is great that you want to utilize the strong features of MongoDB. As you mention you have a solid SQL background. To get the most out of an noSQL Setup, you need to change the way of thinking about schema design. Your first goal will no longer be to get the maximal normalized Schema, Denormalization is not bad, the requirement of your queries will drive your design. The story will start to think about a good schema design. In case you move the SQL normalized Data Model 1:1 to MongoDB you will not have much fun or benefit.

So in a first step I’d suggest to check out if you have a well fitting schema to utilize the MongoDB / noSQL advantages. If this is not the case, please do not worry about DBA issues and setup parameters - most likely you approach would not satisfy you without good data modelling.

That said, DBA and setup parameter should not be underestimated! As start you can try out a sample DB as free tier in MongoDB Altas. This would move away many DBA issues and you can focus on the data modeling. Please also check out MongoDB Compass. Compass is the GUI for MongoDB. You can visually explore your data, run ad hoc queries, interact with your data with full CRUD functionality, view and optimize your query performance and index suggestions.

Unfortunately I am not aware of a compiled list of DBA best practices (@Stennie, @chris, @Doug_Duncan, @Prasad_Saya do you know one this could be of general interest).

You can find further information on the Transitioning from Relational Databases to MongoDB in the linked blog post. Please note also the links at the bottom of this post, and the referenced migration guide .

Since you are new to MongoDB and noSQL I highly recommend to take some of great and free classes from the MongoDB Univerity:

This is just a sample which can get you started very well. In case this is going to be a mission critical project
I’d recommend getting Professional Advice to plan a deployment There are many considerations, and an experienced consultant can provide better advice with a more holistic understanding of your requirements. Some decisions affecting scalability (such as shard key selection) are more difficult to course correct once you have a significant amount of production data.

Hope this helps to start, while getting familiar and all time after, feel free to ask you questions here - we will try to help.


1 Like

Hello @Ashley_Meadows, welcome to the forum.

Just adding to what @michael_hoeller had mentioned, I found that there is a new MongoDB University Course MongoDB for SQL Pros, and this would be of interest to you.

Hi @michael_hoeller and @Prasad_Saya

Thank you for your replies, and the nice welcome into the community :slight_smile:

I appreciate the resources you’ve referenced and will be checking those out this week and certainly looking at the blog post and the Mongo University course. I have some experience with Compass and mongo shell so I feel somewhat comfortable with those.


1 Like

Hi @Ashley_Meadows,

If you are setting up a self-hosted deployment, I recommend reviewing the following documentation:

For a production deployment, I strongly recommend deploying a replica set. Replica sets provides data redundancy, high availability, and administrative flexibility for upgrading and backing up without downtime.

If you are new to MongoDB administration, I would also consider starting with a MongoDB Atlas deployment rather than self-hosting. MongoDB Atlas is a managed database service – you don’t have to worry about the underlying administrative knowledge and tasks to configure, secure, monitor, backup, and scale your MongoDB deployments.

The minimum Atlas cluster deployment is a 3 member replica set running MongoDB Enterprise configured with best practice features such as role-based access control, TLS/SSL network encryption, firewall restrictions, and monitoring. You can configure additional features and behaviour via the Atlas UI or API. With Atlas taking care of the operational aspects of your cluster, you (or your team) can focus on development.

Backing up with rsync is a possible approach (see: Back Up by Copying Underlying Data Files), but to capture a valid backup you need to stop all writes before copying the data files. This will not be an ideal approach if you have a standalone server and cannot afford maintenance windows.

As noted earlier, I would recommend running a replica set in production (especially if you have to support the production deployment). A replica set provides data redundancy so unavailability of a single server (or more, depending on the fault tolerance of your deployment configuration) does not result in downtime. This is extremely useful for rolling maintenance (upgrading one member of your replica set at a time) and mitigating failure scenarios.


1 Like

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.