Mongobyte

use recoverDoc ; for ( i = 0 ; i < 100 ; i ++){ db . col1 . insert ({ _id : i })}; for ( i = 100 ; i < 200 ; i ++){ db . col1 . insert ({ _id : i , name : "some_x_name" })}; > db . col1 . remove ({ "name" : "some_x_name" }) WriteResult ({ "nRemoved" : 100 }) use local ; db . oplog . rs . find ({ op : "i" , ns : "recoverDoc .col1" , "o.name" : "some_x_name" }). count (); 100 db . oplog . rs . find ({ op : "i" , ns : "recoverDoc .col1 " , "o.name" : "some_x_name" }, { "o" : 1 }); { "o" : { "_id" : 100 , "name" : "some_x_name" } } { "o" : { "_id" : 101 , "name" : "some_x_name" } } { "o" : { "_id" : 102 , "name" : "some_x_name" } } { "o" : { ...

Reconfigure replica set member with same coonfiguration as it was earlier: We have replica set of three node cluster.  1 Primary  P1:27001 2 Secondary S1:27002 and S2:27003 S1 server got crashed and need to rebuilt so mongoDB reconfiguration  required. Status at primary looks like this: "set" : "rep1A",         "myState" : 1,         "syncingTo" : "P1:27001",        "members" : [                 {                         "_id" : 0,                         "name" : "P1:27001",             ...

We have log append true in config file. Every day log is appended to the single log file. We are facing issue in space and we were also not able to purge the log file completely. So we need logs file for every day, if we have space issue then we can remove the old logs. Only thing we need to do is: In config file make sure we have: logappend = true Then login to mongo shell, run the below command against the admin database. use admin db.runCommand({logRotate:1})

We are getting continous timeout and duplicate index key error: After checking to the replica set status [rs.status()] , it was found that secondaries are out of sync and stale. And one of the replica set has no Primary Check if secondaries were lagging by rs.printSlaveReplicationInfo() Then we end up with refresh all the secondaries.

We have to migrate data from dev to Prod( Sharded Environment). We will use mongoDump and mongoRestore utility. MongoDump:  Used to create binary export of the contents of the database. It does not include index data. It requires to rebuild index after restoring the data. Futher Reference from MongoDB  MongoRestore: Used to import binary content from dump to the MongoDB instance. Further Reference from MongoDB Take dump from Dev Server as: mongodump  --host  dev_hostname:port  -u user -p ****** --authenticationDatabase db_name_where_authentication_checks --db dbname --collection collection_name   A dump folder created includes bson file. SCP that file to the Production server Then restore as:  mongorestore --host prod_hostname:port  -u user -p ******  --authenticationDatabase db_name_where_authentication_checks  --collection collection_name --db dbname  path_to_dump_bson  ...

Quick Introduction of Wired Tiger Storage Engine: It is the first pluggable storage engine,  new in Mongodb 3.0.  Stores data in B-tree  while MMAPPV1 stores its indexes in B-tree not data.   Wired tiger has two caches (Wired Tiger and File system) for performance improvement.   Provides document level locking in short better concurrency than MMAPV1.  From Mongodb Version 3.2  wired tiger is the default storage engine. Steps to replace existing MMAPV1 storage engine with Wired Tiger Storage Engine on Mongodb version: 3.0.4 We have already running mongod services with three members replica sets having default storage engine (MMAPV1): Here are three mongod processes: mongod --config /data/replset1/conf/rs_member.conf mongod --config /data/replset2/conf/rs_member.conf mongod --config /data/replset3/conf/rs_member.conf Note: If we directly try to restart mongod with –storageEngine parameter then we get fo...