Release Notes for MongoDB 2.2
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.
mongod, 2.2 is a drop-in replacement for 2.0 and 1.8.
Check your driver documentation for information regarding required compatibility upgrades, and always run the recent release of your driver.
Typically, only users running with authentication, will need to upgrade drivers before continuing with the upgrade to 2.2.
For all deployments using authentication, upgrade the drivers (i.e. client libraries), before upgrading the
mongodinstance or instances.
For all upgrades of sharded clusters:
Other than the above restrictions, 2.2 processes can interoperate with 2.0 and 1.8 tools and processes. You can safely upgrade the
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. 
|||To minimize the interruption caused by election process, always upgrade the secondaries of the set first, then
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
mongodand replacing the 2.0 binary with the 2.2 binary. After upgrading a
mongodinstance, wait for the member to recover to
SECONDARYstate before upgrading the next instance. To check the member’s state, issue
rs.stepDown()to step down the primary to allow the normal failover procedure.
rs.stepDown()expedites the failover procedure and is preferable to shutting down the primary directly.
Once the primary has stepped down and another member has assumed
PRIMARYstate, as observed in the output of
rs.status(), shut down the previous primary and replace
mongodbinary with the 2.2 binary and start the new process.
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.
Use the following procedure to upgrade a sharded cluster:
- Disable the balancer.
- Upgrade all
mongosinstances first, in any order.
- Upgrade all of the
mongodconfig server instances using the stand alone procedure. To keep the cluster online, be sure that at all times at least one config server is up.
- Upgrade each shard’s replica set, using the upgrade procedure for replica sets detailed above.
- re-enable the balancer.
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.
For more information, see the Expire Data from Collections by Setting TTL tutorial.
MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements:
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 MongoDB clients and drivers now support full read preferences, including consistent support for a full range of read preference modes and tag sets. This support extends to the
mongos and applies identically to single replica sets and to the replica sets for each shard in a sharded cluster.
MongoDB 2.2 provides more reliable and robust support for authentication clients, including drivers and
If your cluster runs with authentication:
- For all drivers, use the latest release of your driver and check its release notes.
- In sharded environments, to ensure that your cluster remains available during the upgrade process you must use the upgrade procedure for sharded clusters.
In version 2.0 these operations would return an empty document, e.g.
See: SERVER-6226 for more information.