You’re probably hosting your MongoDB on a reliable cloud service provider say Atlas for instance because you really want to focus on your idea and delegate all the subtle key management areas such as networking, storage, access, etc.

It all looks good initially until your small idea starts turning into a business and the cost starts skyrocketing. Even if that is not the case, this post will still give you a general overview of the technical complexities involved (and bucks saved!) if you were to migrate to a self-hosted solution.

BTW, how much savings are we talking about? Let’s do a quick comparison between an Atlas instance and a self-hosted MongoDB on AWS.

Atlas (~$166/month)

$0.23/hour based on the above-selected requirements (~ cloud.mongodb.com)

AWS (~$36/month)

$0.0416/hour for the instance and additional pricing based on the EBS type and storage (~ calculator.aws)

It is almost 4.5x savings just in terms of the infrastructure!

Now that you know the major why(s) and are still reading this post, without further ado, let’s dive into the tech.

---

Outline

1. Setting up the Infrastructure
2. Setting up MongoDB
3. Initial Bulk Migration
4. Delta-sync to bridge the connection switch latency (not applicable to stale clusters)

Since the entire content can be a bit exhausting in one place, I’m going to divide this into two related posts.

---

1. Setting up the Infrastructure

I’m going to mention below the guide for setting up an instance running RedHat Enterprise Linux 8 on AWS. This is because MongoDB generally performs better with the xfsfile-system.

Spin up an EC2 Instance

I’ve used a **t3.small **instance that comes with 2 vCPUs and **2Gb of RAM**albeit you can select any instance of your choice.

_It is recommended that your DB should have access to at least _1GB of RAM_and __2 real cores _or 1 multi-core as that directly affects the performance during caching & concurrency mechanisms when handled by the default engine WiredTiger. You can read more about the production notes related to the RAM and CPU requirements here.

Configuration Overview:

• OS: Redhat Enterprise Linux 8 (x64 intel-based)

• Instance Type: t3.small

• Storage: 10GB(os)** + 30GB**(data)** + 3GB**(logs)of** EBS **i.e. 3 separate volumes

I’m assuming that you’re familiar with creating a VM on AWS.

Now, once the instance is in running state, assign an Elastic IP to it and then simply do a remote login into the machine.

We’ll need the Elastic IP to setup a public hostname for the instance.

$ ssh -i <PEM_FILE> ec2-user@<ELASTIC_IP>

Mount Additional Volumes

We have added 2 additional EBS volumes other than the Root Partition for storing_ Data _and _Logs _which are yet to be mounted (Remember the 30GB and 3GB?). You can list the volume blocks using,

$ sudo lsblk

The additional volumes will be listed right after the root block (refer to the arrows)

In the image above, you can see that the additional volumes are named

1. **xvdb **(30GB space to store data)

2. **xvdc **(3GB space to store logs)

Now, let’s create the file-systems in those volumes.

$ sudo mkfs.xfs -L mongodata /dev/xvdb

$ sudo mkfs.xfs -L mongologs /dev/xvdc

The _-L_ option stands for volume label.

And then mount the volumes.

$ sudo mount -t xfs /dev/xvdb /var/lib/mongo

$ sudo mount -t xfs /dev/xvdc /var/log/mongodb

In order for these changes to reflect, the system must be rebooted. Hence now we also need to ensure partition persistence so that in case of an unintentional reboot we don’t lose the Database storage.

We can achieve this by specifying the mount rules in the fstab file. You can read more about it here.

Before that let’s copy the UUID of the above partitions(because they are unique and won’t change over a system restart)

$ sudo blkid

Refer to the “LABEL” for volume block identification

Copy the UUIDs listed for **/dev/xvdb **and /dev/xvdc.

Now open the /etc/fstab file and paste the configuration in the following format.

UUID=<COPIED_UUID_FOR_DATA> /var/lib/mongo xfs defaults,nofail 0 0

UUID=<COPIED_UUID_FOR_LOGS> /var/log/mongodb xfs defaults,nofail 0 0

The above configuration ensures that the additional volumes with their respective UUIDs will be always mounted with the path **/var/lib/mongo _and _/var/log/mongodb.**

The only caveat is when you spawn another instance from the snapshot of a preconfigured, the changes might not reflect correctly and you’ll have to reboot the system again after either removing or replacing with the correct UUIDs.

#mongodb #mongo #aws #cost-optimization #mongodb-atlas