Learning by Doing

We can use MongoDB Compass to monitor database performance live, which is useful sometimes when we encounter some issues on the database where some queries are taking longer than normal.  In this case, we can kill these queries by first identifying the opid of the long running query using mongodb compass. This is the view of the MongoDB Compass tab,  click into the command on the top of the list of slowest operations Now copy the opid and use any client tool of your choosing, make sure you are connected to the primary node by first identify yourself with rs.isMaster() ismaster should contain the value "true" then  db.killOp(<opid>) Sometimes the transaction may take a few second to kill, and you click into the slowest operation, you can see the pendingKill for this opid is set to true.  

I ran into an issue after I initiated a backup job through opsmanager, which indicated that the db version directory is not available. First I check my version manifest to see if the version that the daemon process is looking for is checked Click on version manager Then we can select the MongoDB versions Since I can see these are checked, I went to the default location where these db versions are stored, then I realized the default location simply does not have enough room to store all these binaries. I had to change the location to store them Default location where OpsManager would download the binary for various versions of MongoDB is /opt/mongodb/mms/mongodb-releases/, we can change it by clicking into admin on top right corner of the page , then General > Ops Manager Config > Miscellaneous, scroll down to Versions Directory and change the value there. Once the change has been made, go back to the terminal and restart the ops manager by running service mon

We have installed and configured multiple monitoring agent to communicate with OpsManager, however, there can only be one active Monitoring Agent at a time. It's good to have multiple monitoring agent because OpsManager is able to switch over to the remaining monitoring agent automatically when the "Active" agent fails. The lightening shape under type indicates they are monitoring agent and note how one is active and one is standby. To switch to another, we need to go to the host where the monitoring agent is running and run  sudo systemctl stop mongodb-mms-monitoring-agent.service Run the folllowing to make sure it's stopped, it will take a few second for the standby monitoring agent to now become active sudo systemctl status mongodb-mms-monitoring-agent.service ● mongodb-mms-monitoring-agent.service - MongoDB MMS Monitoring Agent    Loaded: loaded (/etc/systemd/system/mongodb-mms-monitoring-agent.service; disabled; vendor preset: disa

OpsManager 3.6.5 installation This is just a quick guide for myself, documenting step by step how to implement MongoDB OpsManagernote: mongod version: 3.6.x Download from https://www.mongodb.com/download-center#ops-manager 1. Create backing databases a. OpsManager App DB b. OpsManager Backup DB (Op DB, BlockStore DB) Startup backing app db. sudo -u mongod mongod --port 25001 --dbpath /data/mongod/appDB --logpath /data/mongod/appDBLog/applog1.log --replSet opApp --bind_ip localhost,10.155.228.75 --cpu --fork sudo -u mongod mongod --port 25001 --dbpath /data/mongod/appDB --logpath /data/mongod/appDBLog/applog1.log --replSet opApp --bind_ip localhost,10.155.208.207 --cpu --fork sudo -u mongod  mongod --port 25001 --dbpath /data/mongod/appArb --logpath /data/mongod/appArbLog/appArblog1.log --replSet opApp --cpu --bind_ip localhost,10.155.208.169 --fork on host 75 mongo --port 25001 rs.initiate() run as MongoDB Enterprise opApp:PRIMARY> rs.add({host:&

This is to limit the end user from executing anything that can potentially cause the database slow down with bad queries.  set serverout on size 5555 -- -- first remove an existing active plan ALTER SYSTEM SET RESOURCE_MANAGER_PLAN =''; -- -- delete any existing plan or group -- we have to create a pending area first exec dbms_resource_manager.clear_pending_area(); exec dbms_resource_manager.create_pending_area(); exec dbms_resource_manager.DELETE_PLAN ('LIMIT_EXEC_TIME'); exec dbms_resource_manager.DELETE_CONSUMER_GROUP ('GROUP_WITH_LIMITED_EXEC_TIME'); exec DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA; exec DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA(); begin   dbms_resource_manager.create_pending_area();   --   -- we need a consumer group that maps to the desired oracle user:   dbms_resource_manager.create_consumer_group(     CONSUMER_GROUP=>'GROUP_WITH_LIMITED_EXEC_TIME',     COMMENT=>'This is the