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> })
Related
How can I restore an old MongoDB backup that I believe was made by copying the raw db files? (They did not use a dump command)
It was delivered compressed in a .7z format, which decompressed to the following files:
mydb_2014.1
mydb_2014.2
mydb_2014.3
mydb_2014.4
mydb_2014.5
mydb_2014.ns
I've tried mongorestore but it generates errors saying "don't know what to do with file ..., skipping"
It should be possible to just start up a mongod instance while specifying the path to the files in question:
mongodb --dbpath /path/to/files
You should try to use a version of MongoDB that matches to the version that was in use when the backup was taken. It looks like these files are from the MMAPv1 storage engine, so you may also need to specify --storageEngine mmapv1 if you're using MongoDB 3.2 or later.
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.
I am running a (keystonejs) webapp using mongodb 3.0 as database. I cloned the webapp and run a second instance using a 3.2 mongodb release (on a generated but yet empty data base). What I need to do now is get the data from the first database to the second. Since mongodb 3.2 uses a different default storage engine which is WiredTiger the clone uses that one. However the original app uses MMAPv1. Is there a easy way to migrate data create by MMAPv1 to WiredTiger?
Create a backup of the database on your old server using mongodump, restore it back to the new one using mongorestore, done. It's covered quite well in the documentation.
https://docs.mongodb.org/manual/tutorial/change-standalone-wiredtiger/
You can create replica set and add new machine to it. Doing so, you'll have latest data on newer server. Once replication is over, switch new machine to primary and shutdown old server if you want. This way you can easily clone your existing data to wiredTiger without loosing data or negatively effecting existing application.
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)?
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.