Posts

Showing posts with the label MongoDB

MongoDB Script Get all Indexes Creation Script

MongoDB: Get All Indexes in DB via Mongo Shell This is a simple script to backup all the index creation scripts Note: background:true is deprecated since MongoDB 4.2, but it's okay to leave it in. Options for all Index types To run this, simply save to a script and run it with mongo shell mongo -u admin -p --authenticationDatabase=admin --host localhost getAllIndexesCreationScript.js > output.js db.getMongo().getDBNames().forEach(function(dbName) { if (dbName != "admin" && dbName != "local") { db.getSiblingDB(dbName).getCollectionNames().forEach(function(coll) { db.getSiblingDB(dbName)[coll].getIndexes().forEach(function(index) { if ("_id_" !== index.name) { print("db.getSiblingDB('" + dbName + "')." + coll + ".createIndex(" + tojson(index.key) + ",{background:true}" + ")"); } }); }); } });

MongoDB Log Switch Script

Image
It's been a while since I wrote a post, I have been busy exploring everything I want to learn outside of work and it's been fun. I think it's time to get back and document some more!  Today I want to talk about  log switching.  Having been managing MongoDB databases and MongoDB BI Connector for quite a while now. I can't put enough appreciation of how the logs have helped of making my life so much easier and they should be the one of the first things we check whenever we encounter any issue in regards to the aforementioned.  If you agree with me on how important the log is, please read on. Log is definitely your friend, but I know I had made the mistake of leaving it alone for a long while and when I truly needed it, it became a monster that I had to cut and dissect into workable size.  There was one time we had a production issue and I had to look into the issue immediately and of course I went straight to my friend, the logs. I tried looking into the log and t...

MongoDB tips: get config information

db._adminCommand( {getCmdLineOpts: 1}) db._adminCommand({getParameter:"*"}) rs0:PRIMARY> db._adminCommand( {getCmdLineOpts: 1}) {         "argv" : [                 "mongod",                 "--config=/data/configdb/mongod.conf",                 "--dbpath=/data/db",                 "--replSet=rs0",                 "--port=27017",                 "--bind_ip=0.0.0.0",                 "--auth",                 "--keyFile=/data/configdb/key.txt"         ],         "parsed" : {                 "config" : "/data/configdb/mongod.conf",       ...

MongoDB tips: using explainable object

This is just to quickly document an alternative way to run explain plan assuming this is the query we want to run explain plan 2019-10-12T06:10:44.366-0400 I COMMAND [conn25251540] command device-event-store.events command: find { find: "events", filter: { $and: [ { aggregateId: { identifier: "990003494014489" } }, { version: { $gte: 0 } } ] }, sort: { version: 1 }, $db: "device-event-store", $clusterTime: { clusterTime: Timestamp(1570875044, 17), signature: { hash: BinData(0, 502D14059FA04824080CA91DAB899D434CFA3E87), keyId: 6727232173650214920 } }, lsid: { id: UUID("91bed447-28f5-4211-b3f8-58821d04060d") } } planSummary: COLLSCAN keysExamined:0 docsExamined:56299 hasSortStage:1 cursorExhausted:1 numYields:441 nreturned:78 reslen:44800 locks:{ Global: { acquireCount: { r: 884 } }, Database: { acquireCount: { r: 442 } }, Collection: { acquireCount: { r: 442 } } } protocol:op_msg 232ms first let's create an explainable object with execut...

MongoDB tips: Performance Tuning, Index creation order matters

I am hoping this post will be obsolete and noone will needs to find this. Continue from my previous post about choosing the best index for the job, that certain should still holds true as when I created the index with 1, -1 for two different date field, it's less efficient than -1, -1. Anyway, so luckily I found out about this before rolling this into production as I was planning on the production release. Under lower environment, I realized a less efficient index was used... from my previous post . I now believe it's a bug that should be fixed, in my experiments, the newer index is always preferred even when a better index is present. MongoDB query optimizer looks to be looking into only the first selective field I chose and no further. So if the latest index created matches the field this index is created, so in order for my query to serve the high frequency query, I have to make sure the best index is created last.

MongoDB tips: Performance Tuning, Index key direction MATTERS!

This is the query I am working to make it better, Environment: MongoDB 3.6.6 2019-09-25T11:30:17.696-0400 I COMMAND  [conn19014149] command task.task command: find { find: "task", filter: { $and: [ { _id.boardId.location.correlation: "MN01" }, { $or: [ { _id.boardId.boardDate: new Date(1569384000000) }, { _id.boardId.boardDate: new Date(1569297600000), started: { $exists: true }, ended: { $exists: false }, shift.end: { $gte: new Date(1569384000000) } }, { _id.boardId.boardDate: new Date(1569470400000), started: { $exists: true }, ended: { $exists: false }, shift.start: { $lte: new Date(1569470400000) } } ] } ] }, $db: "task", $clusterTime: { clusterTime: Timestamp(1569425411, 1), signature: { hash: BinData(0, A8F704450DF4EF062ABB018B8BC3C175CE3CC62A), keyId: 6680100327825342465 } }, lsid: { id: UUID("683fbed5-1856-4181-b18f-d06db6b6cbb8") } } planSummary: IXSCAN { _id.boardId.boardDate: 1 }, IXSCAN { _id.boardId.boardDate: 1, personnelAssignm...