To upgrade an existing MongoDB deployment to 2.6, you must be running
2.4. If you’re running a version of MongoDB before 2.4, you must
upgrade to 2.4 before upgrading to 2.6. See
Upgrade MongoDB to 2.4 for the procedure to upgrade from
2.2 to 2.4.

If you use MongoDB Cloud Manager Backup, ensure that you’re running at least version
v20131216.1 of the Backup agent before upgrading. Version 1.4.0 of
the backup agent followed v20131216.1

Some changes in MongoDB 2.6 require manual checks and
intervention. See Compatibility Changes in MongoDB 2.6 for an
explanation of these changes. Resolve all incompatibilities in your
deployment before continuing.

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.

Before beginning the upgrade process for a deployment that uses
authentication and authorization:

If your application performs CRUD operations on the
<database>.system.users collection or uses a
db.addUser()-like method, then you must
upgrade those drivers (i.e. client libraries) beforemongod or mongos instances.

You must fully complete the upgrade procedure for all MongoDB
processes before upgrading the authorization model.

After you begin to upgrade a MongoDB deployment that uses
authentication to 2.6, you cannot modify existing user data until
you complete the authorization user schema upgrade.

Once upgraded to MongoDB 2.6, you cannot downgrade to any version
earlier than MongoDB 2.4. If you created text or 2dsphere
indexes while running 2.6, you can only downgrade to MongoDB 2.4.10 or
later.

The following steps outline the procedure to upgrade a standalone
mongod from version 2.4 to 2.6. To upgrade from version
2.2 to 2.6, upgrade to version 2.4first, and then follow the procedure to
upgrade from 2.4 to 2.6.

Upgrade the secondary members of the set one at a time by
shutting down the mongod and replacing the 2.4 binary
with the 2.6 binary. After upgrading a mongod instance,
wait for the member to recover to SECONDARY state
before upgrading the next instance.
To check the member’s state, issue rs.status() in the
mongo shell.

When rs.status() shows that the primary has stepped down
and another member has assumed PRIMARY state, shut down the
previous primary and replace the mongod binary with the
2.6 binary and start the new instance.

Replica set failover is not instant but will render the set
unavailable accept writes until the failover process
completes. Typically this takes 30 seconds or more: schedule the
upgrade procedure during a scheduled maintenance window.

Only upgrade sharded clusters to 2.6 if all members of the
cluster are currently running instances of 2.4. The only supported
upgrade path for sharded clusters running 2.2 is via 2.4. The upgrade
process checks all components of the cluster and will produce warnings
if any component is running version 2.2.

The upgrade process does not require any downtime. However, while you
upgrade the sharded cluster, ensure that clients do not make changes
to the collection meta-data. For example, during the upgrade, do not
do any of the following:

any other operation that modifies the cluster metadata in any
way. See Sharding Reference for a complete list
of sharding commands. Note, however, that not all commands on
the Sharding Reference page modifies the
cluster meta-data.

Start a single 2.6 mongos instance with
the configDB pointing to the cluster’s config servers and with
the --upgrade option.

To run a mongos with the --upgrade option, you
can upgrade an existing mongos instance to 2.6, or if you
need to avoid reconfiguring a production mongos instance,
you can use a new 2.6 mongos that can reach all the config
servers.

The upgrade will prevent any chunk moves or splits from occurring
during the upgrade process. If the data files have many sharded
collections or if failed processes hold stale locks,
acquiring the locks for all collections can take
seconds or minutes. Watch the log for progress updates.

Upgrade and restart without the --upgrade option the
other mongos instances in the sharded cluster. After
upgrading all the mongos, see
Complete Sharded Cluster Upgrade for information on
upgrading the other cluster components.