Step 1: Stop the existing mongod instance. For example, on Linux, run 2.4 mongod with the --shutdown option as follows: 

mongod --dbpath /var/mongod/data --shutdown 

Replace /var/mongod/data with your MongoDB dbPath . See also the Stop mongod Processes (page 225) for alternate methods of stopping a mongod instance. 

Step 2: Start the new mongod instance. Ensure you start the 2.6 mongod with the same dbPath : 

mongod --dbpath /var/mongod/data 

Replace /var/mongod/data with your MongoDB dbPath . 

## Additional Resources 

• MongoDB Major Version Upgrade Consulting Package 674 

Upgrade User Authorization Data to 2.6 Format MongoDB 2.6 includes significant changes to the authorization model, which requires changes to the way that MongoDB stores users’ credentials. As a result, in addition to upgrading MongoDB processes, if your deployment uses authentication and authorization, after upgrading all MongoDB process to 2.6 you must also upgrade the authorization model. 

## Considerations 

Complete all other Upgrade Requirements Before upgrading the authorization model, you should first upgrade MongoDB binaries to 2.6. For sharded clusters, ensure that all cluster components are 2.6. If there are users in any database, be sure you have at least one user in the admin database before upgrading the MongoDB binaries. 

Timing Because downgrades are more difficult after you upgrade the user authorization model, once you upgrade the MongoDB binaries to version 2.6, allow your MongoDB deployment to run a day or two without upgrading the user authorization model. 

This allows 2.6 some time to “burn in” and decreases the likelihood of downgrades occurring after the user privilege model upgrade. The user authentication and access control will continue to work as it did in 2.4, but it will be impossible to create or modify users or to use user-defined roles until you run the authorization upgrade. 

If you decide to upgrade the user authorization model immediately instead of waiting the recommended “burn in” period, then for sharded clusters, you must wait at least 10 seconds after upgrading the sharded clusters to run the authorization upgrade script. 

Replica Sets For a replica set, it is only necessary to run the upgrade process on the primary as the changes will automatically replicate to the secondaries. 

Sharded Clusters For a sharded cluster, connect to a mongos and run the upgrade procedure to upgrade the cluster’s authorization data. By default, the procedure will upgrade the authorization data of the shards as well. 

To override this behavior, run the upgrade command with the additional parameter upgradeShards: false . If you choose to override, you must run the upgrade procedure on the mongos first, and then run the procedure on the primary members of each shard. 

