In this recipe, we will look at how to migrate existing data onto a new storage engine. MongoDB does not allow on the fly (live) migrations, so we will have to do it the hard way.
- Start the mongod daemon to explicitly use MMAPv1 storage engine:
/data/mongodb/bin/mongod --dbpath /data/db --storageEngine mmapv1- Start the mongo client and you should be presented with the MongoDB shell. Execute the following commands in the shell:
> var status = db.serverStatus() > status['storageEngine'] { "name" : "mmapv1", "supportsCommittedReads" : false, "readOnly" : false, "persistent" : true }
- Now let's add some random data into it. Run the following JavaScript code to insert 100 documents with random data:
> use mydb > for(var x=0; x<100; x++){ db.mycol.insert({ age:(Math.round(Math.random()*100)%20) }) } > db.mycol.count() 100
- Exit the shell and perform a full backup using
mongodumpcommand:
mkdir /data/backup mongodump -o /data/backup --host localhost:27017
- Now shutdown the mongod process.
- Create a new data directory for the migration and start the mongod daemon with a new storage engine:
mkdir /data/newdb /data/mongodb/bin/mongod --dbpath /data/newdb --storageEngine wiredTiger
- Let's restore the previous backup to this new instance:
mongorestore /data/backup/- Start the mongo shell and check your data:
> var status = db.serverStatus() > status['storageEngine'] { "name" : "wiredTiger", "supportsCommittedReads" : true, "readOnly" : false, "persistent" : true } > use mydb switched to db mydb > db.mycol.count() 100
As WiredTiger is the default storage engine for MongoDB 3.2, for this exercise, we explicitly started a MongoDB instance with MMAPv1 storage engine in step 1. In step 2, we stored the db.serverStatus() command's output in a temporary variable to inspect the output of the server's storageEngine key. This helps us see which storage engine our MongoDB instance is running on. In step 3, we switched to database mydb and ran a simple JavaScript function to add 100 documents to a collection called mycol. Next, in step 4, we created a backup directory /data/backup which is passed as a parameter to mongodump utility. We will discuss more about the mongodump utility in Chapter 6, Managing MongoDB Backups.
Once we shutdown the mongod instance, in step 5, we are now ready to start a new instance of MongoDB but this time with WiredTiger storage engine. We follow the basic practice of covering for failure and instead of removing /data/db, we create a new path for this instance (#AlwaysHaveABackupPlan). Our new MongoDB instance is empty, so in step 7 we import the aforementioned backup into the database using the mongorestore utility. As the new MongoDB instance is running WiredTiger storage engine, our backup (which is essentially BSON data) is restored and saved on disk using this storage engine. Lastly, in step 8, we simply inspect the storageEngine key on the db.serverStatus() output and confirm that we are indeed using WiredTiger.
As you can see, this is an overly simplistic example of how to convert MongoDB data from one storage engine format to another. One has to keep in mind that this operation will take a significant amount of time depending on the size of data. However, application downtime can be averted if we were to use a replica set. More on this later.