Note

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.

Aggregation Framework

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:

• Documentation: Aggregation
• Reference: Aggregation Reference

TTL Collections

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.

Concurrency Improvements

MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements:

1. DB Level Locking
2. Improved Yielding on Page Faults
3. Improved Page Fault Detection on Windows

To reflect these changes, MongoDB now provides changed and improved reporting for concurrency and use. See locks, recordStats , db.currentOp(), mongotop, and mongostat.

Improved Data Center Awareness with Tag Aware Sharding

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:

• sh.addShardTag()
• sh.addTagRange()
• sh.removeShardTag()

Fully Supported Read Preference Semantics

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.

Additional read preference support now exists in the mongo shell using the readPref() cursor method.

Authentication Changes

MongoDB 2.2 provides more reliable and robust support for authentication clients, including drivers and mongos instances.

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.

findAndModify Returns Null Value for Upserts that Perform Inserts

In version 2.2, for upsert that perform inserts with the new option set to false, findAndModify commands will now return the following output:

{ 'ok': 1.0, 'value': null }

In the mongo shell, upsert findAndModify operations that perform inserts (with new set to false.)only output a null value.

In version 2.0 these operations would return an empty document, e.g. { }.

See: SERVER-6226 for more information.

mongodump 2.2 Output Incompatible with Pre-2.2 mongorestore