In this chapter, we will cover the following recipes related to MongoDB administration:
- Renaming a collection
- Viewing collection stats
- Viewing database stats
- Disabling the preallocation of data files
- Manually padding a document
- Understanding the mongostat and mongotop utilities
- Estimating the working set
- Viewing and killing the currently executing operations
- Using profiler to profile operations
- Setting up users in MongoDB
- Understanding interprocess security in MongoDB
- Modifying collection behavior using the collMod command
- Setting up MongoDB as a Windows Service
- Configuring a replica set
- Stepping down as a primary instance from the replica set
- Exploring the local database of a replica set
- Understanding and analyzing oplogs
- Building tagged replica sets
- Configuring the default shard for nonsharded collections
- Manually splitting and migrating chunks
- Performing domain-driven sharding using tags
- Exploring the config database in a sharded setup
Have you ever come across a scenario where you have named a table in a relational database, and at a later point of time, felt that the name could have been better? Or perhaps, the organization you work for was late in realizing that the table names are really getting messy and wants to enforce some standards on the names? Relational databases do have some proprietary ways to rename the tables, and a database admin can do that for you.
This raises a question though. In the Mongo world, where collections are synonymous with tables, is there a way to rename a collection after it is created? In this recipe, we will explore this feature of Mongo, where we rename an existing collection with some data in it.
Running a MongoDB instance is what we will need for performing this collection renaming experiment. Refer to the Single node installation of MongoDB recipe in Chapter 1, Installing and Starting the MongoDB Server, for how to start the server. The operations we will be performing would be from the Mongo shell.
Let's take a look at the steps in detail:
- Once the server is started, and assuming it is listening for client connections on the default port
27017, execute the following command to connect to it from the shell:> mongo - Once connected, using the default
testdatabase, let us create a collection with some test data. The collection we will be using is namedsloppyNamedCollection:> for(i = 0 ; i < 10 ; i++) db.sloppyNamedCollection.insert({'i':i}) - The test data will now be created (we may verify the data by querying the
sloppyNamedCollectioncollection). - Rename the collection as
neatNamedCollectionusing the following command:> db.sloppyNamedCollection.renameCollection('neatNamedCollection') { "ok" : 1 }
- Verify that the
sloppyNamedCollectioncollection is no longer present, by executing the following command:> show collections - Finally, query the
neatNamedCollectioncollection to verify that the data that was originally insloppyNamedCollectionis indeed present in it. Simply execute the following command on the Mongo shell:> db.neatNamedCollection.find()
Renaming a collection is pretty simple. It is accomplished with the renameCollection method, which takes two arguments. Generally, the function signature is as follows:
> db.<collection to rename>.renameCollection('<target name of the collection>', <drop target if exists>)
The first argument is the name by which the collection is to be renamed.
The second parameter that we didn't use is a Boolean value that tells the command whether to drop the target collection (if it exists) or not. This value defaults to false, which means the target must not be dropped but must give an error instead. This is a sensible default, else the results would be ghastly if we accidentally gave a collection name that exists and didn't wish to drop it. If however, you know what you are doing and want the target to be dropped while renaming the collection, pass the second parameter as true. The name of this parameter is dropTarget. In our case, the call would have been:
> db.sloppyNamedCollection.renameCollection('neatNamedCollection', true)
Now, as an exercise, try creating sloppyNamedCollection again and rename it without the second parameter (or false as the value). You should see Mongo complaining that the target namespace exists. Then, rename it again with the second parameter as true. This time, the renaming operation executes successfully.
Note that the rename operation will keep the original and the newly renamed collection in the same database. This renameCollection method is not enough to move/rename the collection across another database. In such cases, we need to run the renameCollection command as follows:
> db.runCommand({ renameCollection: "<source_namespace>", to: "<target_namespace>", dropTarget: <true|false> });
In our case, suppose we want to move sloppyNamedCollection from the test database to newDatabase, rename it neatNamedCollection, and drop the target database if it exists; we will execute the following command:
> db.runCommand({ renameCollection: "test.sloppyNamedCollection", to: "newDatabase.neatNamedCollection", dropTarget: true });
Also, note that the rename collection operation doesn't work on sharded collections.