{"id":1959,"date":"2024-05-12T19:47:19","date_gmt":"2024-05-12T23:47:19","guid":{"rendered":"https:\/\/enterpriseadmins.org\/blog\/?p=1959"},"modified":"2024-05-12T19:52:04","modified_gmt":"2024-05-12T23:52:04","slug":"creating-a-mongodb-replica-set","status":"publish","type":"post","link":"https:\/\/enterpriseadmins.org\/blog\/scripting\/creating-a-mongodb-replica-set\/","title":{"rendered":"Creating a MongoDB Replica Set"},"content":{"rendered":"\n

I was recently looking at the Aria Operations Management Pack for MongoDB (https:\/\/docs.vmware.com\/en\/VMware-Aria-Operations-for-Integrations\/9.0\/Management-Pack-for-MongoDB\/GUID-73744E17-88DD-49A1-8B86-5BD896C874D8.html<\/a>) and wanted to kick the tires in my vSphere-based lab. To be able to test this management pack, I wanted to deploy a three node MongoDB replica set.

To begin, I found a solid starting point, the Bitnami MongoDB appliance: https:\/\/bitnami.com\/stack\/mongodb\/virtual-machine<\/a>. I downloaded this appliance which included MongoDB 7.0.9 pre-installed.

I deployed three copies of the appliance, specifying static IPs during the deployment. I pre-created forward and reverse DNS records for these IPs. The VMs come configured with 1vCPU and 1GB of RAM. When doing a replica set, I ran into a few issues with only 1GB of RAM, having 2GB of RAM seemed better. Once the VMs were powered on, I logged in with the bitnami\/bitnami username\/password combination and changed the bitnami password. I then made a few changes I made in the OS using the vSphere web console.<\/p>\n\n\n\n

sudo nano \/etc\/ssh\/sshd_config\n# find PasswordAuthentication no and change to yes\n\nsudo rm \/etc\/ssh\/sshd_not_to_be_run\nsudo systemctl start sshd<\/code><\/pre>\n\n\n\n
This allowed me to login over SSH to make the remaining changes.  Over SSH I made some additional changes to allow MongoDB to be accessed remotely:<\/p>\n\n\n\n
sudo nano \/etc\/nftables.conf  # find and add \"tcp dport { 27017-27019 } accept\" in the section below accepting tcp22\nsudo nft -f \/etc\/nftables.conf -e<\/code><\/pre>\n\n\n\n
I also wanted to clean up a couple of general networking issues, namely setting the hostname of the VM and removing an extra secondary IP address that might get pulled via DHCP.<\/p>\n\n\n\n
# set the OS hostname\necho mongo-xx.lab.example.com | sudo tee \/etc\/hostname\n\n# disable the DHCP interface if using static addresses\nsudo nano \/etc\/network\/interfaces\n# find the line at the end of the file for 'iface ens192 inet dhcp' and remove it or make it a comment.\n\n# confirm DNS resolution is configured\nsudo nano \/etc\/resolv.conf  # review for nameserver entries\n\nsudo systemctl restart networking<\/code><\/pre>\n\n\n\n
Next up, we will make some changes to the MongoDB to support our replica set.  We need a security key for nodes to talk with each other.  Instead of using a short password, from my local machine running PowerShell, I created a new GUID to use as a security key for node communication and removed the hyphens.<\/p>\n\n\n\n
[guid]::NewGuid() -Replace '-', ''<\/code><\/pre>\n\n\n\n
For me, this created the string 88157a33a9dc499ea6b05c504daa36f8<\/code> which I’ll reference in the document.  There are other ways to create longer\/more complex keys, but this was something quick.  We need to put this key in a file that will be referenced in a mongo config file.  To create the security key we’ll use the following command:<\/p>\n\n\n\n
echo '88157a33-a9dc-499e-a6b0-5c504daa36f8' | sudo tee \/opt\/bitnami\/mongodb\/conf\/security.key\nsudo chmod 400 \/opt\/bitnami\/mongodb\/conf\/security.key\nsudo chown mongo:mongo \/opt\/bitnami\/mongodb\/conf\/security.key<\/code><\/pre>\n\n\n\n
Now that we have that security key, we’ll update our mongo config.<\/p>\n\n\n\n
sudo nano \/opt\/bitnami\/mongodb\/conf\/mongodb.conf\n\n# Find and remove the comments for replication and replSetName, and set a replication set name if desired.\n\n# uncomment #keyFile at the end of the file and set value to \/opt\/bitnami\/mongodb\/conf\/security.key\n\n# save the file, restart services\nsudo systemctl restart bitnami.mongodb.service<\/code><\/pre>\n\n\n\n
Now that the cluster nodes are all prepared, we can turn this into a replica set cluster.  Since I’m not familiar with this process, I decided to create snapshots of all the nodes (PowerCLI makes this easy — get-vm mongo-0* | New-Snapshot -Name 'Pre RS config'<\/code>) and reboot them for good measure.  I’ll log back into the first node of the cluster over SSH and enter the mongo shell interface, using the root password found on the virtual appliance console.<\/p>\n\n\n\n
mongosh --username root\n# enter the root password\n\n# initiate the cluster\nrs.initiate( {\n   _id : \"replicaset\",\n   members: [\n      { _id: 0, host: \"mongo-01.lab.example.com:27017\" },\n      { _id: 1, host: \"mongo-02.lab.example.com:27017\" },\n      { _id: 2, host: \"mongo-03.lab.example.com:27017\" }\n   ]\n})\n\n# check the status to ensure cluster is working\nrs.status()<\/code><\/pre>\n\n\n\n
The rs.status()<\/code> command should return the status of the cluster.  We should see one of our nodes is the primary and the other two are secondary (based on the stateStr<\/code> property).  <\/p>\n\n\n\n
With our replica set working, we can now start monitoring. The next post (link<\/a>) will cover installing and configuring the management pack. The final post in this series (link<\/a>) will show how to import some sample data and run sample queries to put read load on the replica set.<\/p>\n","protected":false},"excerpt":{"rendered":"
I was recently looking at the Aria Operations Management Pack for MongoDB (https:\/\/docs.vmware.com\/en\/VMware-Aria-Operations-for-Integrations\/9.0\/Management-Pack-for-MongoDB\/GUID-73744E17-88DD-49A1-8B86-5BD896C874D8.html) and wanted to kick the tires in my vSphere-based lab. To be able to test this management pack, I wanted to deploy a three node MongoDB replica … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[9,3,4],"tags":[],"class_list":["post-1959","post","type-post","status-publish","format-standard","hentry","category-lab-infrastructure","category-scripting","category-virtualization"],"_links":{"self":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/1959","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/comments?post=1959"}],"version-history":[{"count":11,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/1959\/revisions"}],"predecessor-version":[{"id":1990,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/posts\/1959\/revisions\/1990"}],"wp:attachment":[{"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/media?parent=1959"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/categories?post=1959"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enterpriseadmins.org\/blog\/wp-json\/wp\/v2\/tags?post=1959"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}