MongoDB multi-granularity locking - mongodb

MongoDB uses multi-granularity locking [1] that allows operations to lock at the global, database or collection level, and allows for individual storage engines to implement their own concurrency control below the collection (i.e., at the document-level in WiredTiger).
Besides I've read that there are two possible Storage Engines for MongoDB: MMAPv1 (default) and WiredTiger. From MongoDB 3.0, the first one uses collection-level locking, the second one document-level locking. What does it mean that MongoDB allows operations to lock at the GLOBAL, DATABASE or COLLECTION level? It means that I can choose lock granularity? If yes how I can do it? Is this in contrast with lock-granularity of the chosen storage engine (for example document-level in WiredTiger)?
And how can I change my storage engine from MMAPv1 to WiredTiger?
Thanks in advance.

Answer to
And how can I change my storage engine from MMAPv1 to WiredTiger?
This page explains it:
Start 3.0 mongod. Ensure that the 3.0 mongod is running with the default MMAPv1 engine.
Export the data using mongodump.
mongodump --out <exportDataDestination>
Specify additional options as appropriate, such as username and password if running with authorization enabled. See mongodump for available options.
Create data directory for WiredTiger.
Create a new data directory for WiredTiger. Ensure that the user account running mongod has read and write permissions for the new directory.
mongod with WiredTiger will not start with data files created with a different storage engine.
Restart the mongod with WiredTiger.
Restart the 3.0 mongod, specifying wiredTiger as the --storageEngine and the newly created data directory for WiredTiger as the --dbpath. Specify additional options as appropriate.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath>
You can also specify the options in a configuration file. To specify the storage engine, use the new storage.engine setting.

Related

Using Mongo Cache as a replacement for redis

Currently, i am writing data into redis which is reduced to mongo every 2 minutes. I am wondering if i can use Mongo Cache instead of redis here. This will save the cost of 2 dbs in production.Also,the mongodb page says :
The WiredTiger cache stores uncompressed data and provides in-memory-like performance
I want to test it but i am not able to find any documentation for playing around with WiredTiger Cache.
Note: Wiredtiger is default mongo storage engine.
You can run Mongo DB as a replacement for Redis by specifying the In Memory storage engine:
mongod --storageEngine inMemory --dbpath <path>
You can read more about it here.
I may be wrong, but I believe that you will still need to run 2 Mongo DB servers, one running in Wired Tiger for disk storage, and the other running with In Memory storage for your cache service.

Read concern level of majority error while upgrading Sharded Cluster from 3.2 to 3.4

I have upgraded MongodDB sharded cluster having two replica sets from 3.2 to 3.4. Current storage engine is MMAPv1. After successfully upgrading all the secondary, primary, config server and mongos to 3.4, when I run config server using following command.
sudo mongod --configsvr
I keep getting following Error.
SHARDING [shard registry reload] Periodic reload of shard registry failed :: caused by :: 115 could not get updated shard list from config server due to Current storage engine does not support majority readConcerns; will retry after 30s
And also I am unable to connect mongos with config server. When I try to connect it using following command
sudo mongos --configdb [ip-of-my-config-server]:27019
It gives me following error.
BadValue: configdb supports only replica set connection string
I suppose mongos is unable to connect to config server due to the majority readConcerns error on config server.
MongoDB manual says
"When reading from the replica set config servers, MongoDB 3.4 uses a Read Concern level of "majority"."
And to use a read concern level of "majority", WiredTiger must be used as storage engine.
So it seems I have to switch to WiredTiger storage engine to make it work. But when I was going to switch to WiredTiger storage engine of a secondary replica set member, according to manual
"This procedure completely removes a secondary replica set member’s data"
So I am stuck halfway. Situation is
Config server is giving error regarding majority readConcerns.
I have to switch to WiredTiger to get rid of it.
Switching to WiredTiger will remove data from secondary members.
Data will not be replicated back to secondary members during this switching to WiredTiger procedure because of config server error and eventually I will be ended up losing all the data (Please correct if I am wrong).
Questions are:
Can I make MongoDB 3.4 to use a Read Concern level of "local" when reading from the replica set config servers?
How can I switch to WiredTiger engine without losing data in my scenario?
You could migrate each node in the replica set as if it was a standalone, by using mongodump to back up the data, restarting with WiredTiger and a blank data directory, then using mongorestore to populate the new database.
This isn't normally recommended for replica set nodes, but only because it's just easier to wipe the data on a secondary and let it resync from the other nodes. Doing it this way will work just fine, but involves a little more fiddly work for you with the dump and restore tools.

Change storage engine of MongoDB

I STORAGE [initandlisten] exception in initAndListen: 28574 Cannot start server. Detected data files in /data/db created by storage engine 'wiredTiger'. The configured storage engine is 'mmapv1'., terminating ....
https://docs.mongodb.com/manual/tutorial/change-standalone-wiredtiger/
I found this link thinking of any help but it says that you have to start mongod first which is not starting right now.
If you have multiple nodes in a replica set, changing from MMAPv1 to WiredTiger is as simple as for each node :
- stop the node
- delete the database file
- restart the node on WiredTiger (with --storageEngine wiredTiger if version less than 3.2)
The node will now replicate all it's database from the primary using the new format.
If you have a single node installation. You need to use mongodump/mongorestore to dump your database, stop the standalone node, remove the database directory, restart the node with WiredTiger and restore your backup.

Change Storage Engine to WiredTiger for data from mongo backup

we are running mongodb 2.6.1 and we would like to upgrade to 3.*
My question is that since we need to change storage engine can we do it with files that come from mongodb backup, instead of making mongodump/mongorestore (as it says in docs)?

Adding compression to existing mongodb collection

Is it possible to add compression to an existing collection that was created prior to mongodb 3.x? If so, how?
I found an example of how to create a new collection with compression, but I haven't found anything as far as strategies for adding compression to an existing one.
http://www.mongodb.com/blog/post/new-compression-options-mongodb-30
Version prior to 3.x MongoDB had only one storage engine - MMAPv1 which still does not support compression. With 3.0 MongoDB introduced pluggable storage engines, and one of them - wiredTiger storage engine supports compression.
The problem is that you cannot use data files created with one storage engine (say MMAPv1) with another one (e.g. wiredTiger).
So the only thing you can do is just mongodump, initialise mongod with --storageEngine wiredTiger using another data directory (with --dbpath), and then mongorestore to your new mongod instance.
There are several ways to compress mongodb collection.
1) repair collection using command "mongod --repair"
or by running command "db.repairDatabase()"
2) using db.runCommand({ compact: <collection name> })