MongoDB 2.2 is a production release series and succeeds the 2.0
production release series.

MongoDB 2.0 data files are compatible with 2.2-series binaries without any
special migration process. However, always perform the upgrade process for replica
sets and sharded clusters using the procedures that follow.

Other than the above restrictions, 2.2 processes can interoperate with
2.0 and 1.8 tools and processes. You can safely upgrade the
mongod and mongos components of a deployment
one by one while the deployment is otherwise operational. Be sure to
read the detailed upgrade procedures below before upgrading production
systems.

[1]

To minimize the interruption caused by
election process, always upgrade the
secondaries of the set first, then stepdown the primary, and then upgrade the primary.

You can upgrade to 2.2 by performing a “rolling”
upgrade of the set by upgrading the members individually while the
other members are available to minimize downtime. Use the following
procedure:

Upgrade the secondary members of the set one at a time by
shutting down the mongod and replacing the 2.0 binary
with the 2.2 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.

Once the primary has stepped down and another member has assumed
PRIMARY state, as observed in the output of
rs.status(), shut down the previous primary and replace
mongod binary with the 2.2 binary and start the new
process.

Note

Replica set failover is not instant but will
render the set unavailable to read or accept writes
until the failover process completes. Typically this takes
10 seconds or more. You may wish to plan the upgrade during
a predefined maintenance window.

Balancing is not currently supported in mixed 2.0.x and 2.2.0
deployments. Thus you will want to reach a consistent version for all
shards within a reasonable period of time, e.g. same-day.
See SERVER-6902 for more information.

The aggregation framework makes it possible to do aggregation
operations without needing to use map-reduce. The
aggregate command exposes the aggregation framework, and the
aggregate() helper in the mongo shell
provides an interface to these operations. Consider the following
resources for background on the aggregation framework and its use:

TTL collections remove expired data from a collection, using a special
index and a background thread that deletes expired documents every
minute. These collections are useful as an alternative to
capped collections in some cases, such as for data
warehousing and caching cases, including: machine generated event data,
logs, and session information that needs to persist in a database
for only a limited period of time.

MongoDB 2.2 adds additional support for geographic distribution or
other custom partitioning for sharded collections in clusters. By using this “tag aware” sharding, you can
automatically ensure that data in a sharded database system is always
on specific shards. For example, with tag aware sharding, you can
ensure that data is closest to the application servers that use that
data most frequently.

Shard tagging controls data location, and is complementary but
separate from replica set tagging, which controls read
preference and write concern. For example, shard tagging can pin all
“USA” data to one or more logical shards, while replica set tagging
can control which mongod instances (e.g. “production”
or “reporting”) the application uses to service requests.

See the documentation for the following helpers in the mongo
shell that support tagged sharding configuration:

All capped collections now have an _id
field by default, if they exist outside of the local database,
and now have indexes on the _id field. This change only affects capped
collections created with 2.2 instances and does not affect existing
capped collections.

The $elemMatch operator allows applications to narrow
the data returned from queries so that the query operation will only
return the first matching element in an array. See the
$elemMatch reference and the
SERVER-2238 and SERVER-828 issues for more
information.

Labeled “2008+” on the Downloads Page, this build for 64-bit
versions of Windows Server 2008 R2 and for Windows 7 or newer, offers
increased performance over the standard 64-bit Windows build of
MongoDB. See SERVER-3844 for more information.

When you specify the --collection
option to mongodump, mongodump will now backup
the definitions for all indexes that exist on the source
database. When you attempt to restore this backup with
mongorestore, the target mongod will rebuild all
indexes. See SERVER-808 for more information.

mongorestore now includes the --noIndexRestore option to provide the preceding
behavior. Use --noIndexRestore
to prevent mongorestore from building
previous indexes.

mongotop and mongostat now contain support for
username/password authentication. See SERVER-3875 and
SERVER-3871 for more information regarding this change. Also
consider the documentation of the following options for additional
information:

mongoimport now provides an option to halt the import if
the operation encounters an error, such as a network interruption, a
duplicate key exception, or a write error.
The --stopOnError option
will
produce an error rather than silently continue importing data. See
SERVER-3937 for more information.

In mongorestore, the --w
option provides support for configurable write concern.

Previously, mongoimport would only import documents that
were less than 4 megabytes in size. This issue is now corrected, and
you may use mongoimport to import documents that are at
least 16 megabytes ins size. See SERVER-4593 for more
information.

To improve performance, MongoDB 2.2 uses the TCMalloc memory
allocator from Google Perftools. For more information about this
change see the SERVER-188 and SERVER-4683. For more
information about TCMalloc, see the documentation of TCMalloc itself.

When secondary members of a replica set fall behind in
replication, mongod now provides better reporting in the
log. This makes it possible to track replication in general and
identify what process may produce errors or halt replication. See
SERVER-3575 for more information.

The new replSetSyncFrom command and new
rs.syncFrom() helper in the mongo shell make it
possible for you to manually configure from which member of the set a
replica will poll oplog entries. Use these commands to
override the default selection logic if needed. Always exercise
caution with replSetSyncFrom when overriding the default
behavior.

Replica Set Members will not Sync from Members Without Indexes Unless buildIndexes:false¶

To prevent inconsistency between members of replica sets, if the
member of a replica set has
buildIndexes set to true,
other members of the replica set will not sync from this member,
unless they also have
buildIndexes set to
true. See SERVER-4160 for more information.

By default, when replicating options, secondaries
will pre-fetch Indexes associated with a query to improve replication
throughput in most cases. The replication.secondaryIndexPrefetch setting and
--replIndexPrefetch option allow administrators to disable
this feature or allow the mongod to pre-fetch only the
index on the _id field. See SERVER-6718 for more information.

If your shard key uses the prefix of an existing index, then you do not
need to maintain a separate index for your shard key in addition to
your existing index. This index, however, cannot be a multi-key
index. See the Shard Key Indexes documentation and
SERVER-1506 for more information.