MongoDB Documentation, Release 3.0.4 • While the upgrade is in progress, you cannot make changes to the collection meta-data. For example, during the upgrade, do not perform: – sh.enableSharding() , – sh.shardCollection() , – sh.addShard() , – db.createCollection() , – db.collection.drop() , – db.dropDatabase() , – any operation that creates a database, or – any other operation that modifies the cluster meta-data in any way. See Sharding Reference (page 736) for a complete list of sharding commands. Note, however, that not all commands on the Sharding Reference (page 736) page modifies the cluster meta-data. • Once you upgrade to 2.4 and complete the upgrade procedure do not use 2.0 mongod and mongos processes in your cluster. 2.0 process may re-introduce old meta-data formats into cluster meta-data. 1. Before you start the upgrade, ensure that the amount of free space on the filesystem for the config database (page 737) is at least 4 to 5 times the amount of space currently used by the config database (page 737) data files. 2. Turn off the balancer (page 684) in the sharded cluster , as described in Disable the Balancer (page 717). For additional security during the upgrade, you can make a backup of the config database using mongodump or other backup tools. You may have {v:0} indexes on other databases in the cluster. If any index on the config database is {v:0} , you should rebuild those indexes by connecting to the mongos and either: rebuild all indexes using the db.collection.reIndex() method, or drop and rebuild specific indexes using db.collection.dropIndex() and then db.collection.ensureIndex() . If you need to upgrade the _id index to {v:1} use db.collection.reIndex() . To check the version of your indexes, use db.collection.getIndexes() . The duration of the metadata upgrade depends on the network latency between the node performing the upgrade and the three config servers. Ensure low latency between the upgrade process and the config servers. Additionally, ensure that all indexes in the config database (page 737) are {v:1} indexes. If a critical index is a {v:0} index, chunk splits can fail due to known issues with the {v:0} format. {v:0} indexes are present on clusters created with MongoDB 2.0 or earlier. Do not perform operations that modify meta-data while performing this procedure. See Upgrade a Sharded Cluster from MongoDB 2.2 to MongoDB 2.4 (page 893) for examples of prohibited operations. Meta-data Upgrade Procedure Changes to the meta-data format for sharded clusters, stored in the config database (page 737), require a special meta-data upgrade procedure when moving to 2.4. The upgraded config database will require more storage space than before, to make backup and working copies of the config.chunks (page 739) and config.collections (page 740) collections. As always, if storage require- ments increase, the mongod might need to pre-allocate additional data files. See How can I get information on the storage use of a database? (page 777) for more information. Optional Chapter 12. Release Notes 894