发布于 2015-09-14 14:43:45 | 154 次阅读 | 评论: 0 | 来源: 网络整理
See the full index of this page for a complete list of changes included in 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.
Always upgrade to the latest point release in the 2.2 point release. Currently the latest release of MongoDB is 2.2.3.
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 mongod instance 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 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 step down 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.
Use the mongo shell method 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 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.
注解
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:
注解
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 db.collection.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 通过设置TTL使集合中的数据过期 tutorial.
MongoDB 2.2 increases the server’s capacity for concurrent operations with the following improvements:
To reflect these changes, MongoDB now provides changed and improved reporting for concurrency and use, see locks and recordStats in server status and see current operation output, db.currentOp(), mongotop, and mongostat.
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:
Also, see Tag Aware Sharding.
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.
MongoDB 2.2 provides more reliable and robust support for authentication clients, including drivers and mongos instances.
If your cluster runs with authentication:
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.
If you use the mongodump tool from the 2.2 distribution to create a dump of a database, you may only restore that dump to a 2.2 database.
See: SERVER-6961 for more information.
In version 2.2, the ObjectId.toString() method returns the string representation of the ObjectId() object and has the format ObjectId("...").
Consider the following example that calls the toString() method on the ObjectId("507c7f79bcf86cd7994f6c0e") object:
ObjectId("507c7f79bcf86cd7994f6c0e").toString()
The method now returns the string ObjectId("507c7f79bcf86cd7994f6c0e").
Previously, in version 2.0, the method would return the hexadecimal string 507c7f79bcf86cd7994f6c0e.
If compatibility between versions 2.0 and 2.2 is required, use ObjectId().str, which holds the hexadecimal string value in both versions.
In version 2.2, the ObjectId.valueOf() method returns the value of the ObjectId() object as a lowercase hexadecimal string.
Consider the following example that calls the valueOf() method on the ObjectId("507c7f79bcf86cd7994f6c0e") object:
ObjectId("507c7f79bcf86cd7994f6c0e").valueOf()
The method now returns the hexadecimal string 507c7f79bcf86cd7994f6c0e.
Previously, in version 2.0, the method would return the object ObjectId("507c7f79bcf86cd7994f6c0e").
If compatibility between versions 2.0 and 2.2 is required, use ObjectId().str attribute, which holds the hexadecimal string value in both versions.
In version 2.2, collection names cannot:
This change does not affect collections created with now illegal names in earlier versions of MongoDB.
These new restrictions are in addition to the existing restrictions on collection names which are:
Collections names may have any other valid UTF-8 string.
See the SERVER-4442 and the Are there any restrictions on the names of Collections? FAQ item.
Database names running on Windows can no longer contain the following characters:
/. "*<>:|?
The names of the data files include the database name. If you attempt to upgrade a database instance with one or more of these characters, mongod will refuse to start.
Change the name of these databases before upgrading. See SERVER-4584 and SERVER-6729 for more information.
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.
See: SERVER-5516 for more information.
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 (projection) documentation and the SERVER-2238 and SERVER-828 issues for more information.
As of 2.2, MongoDB does not support Windows XP. Please upgrade to a more recent version of Windows to use the latest releases of MongoDB. See SERVER-5648 for more information.
You may now run mongos.exe instances as a Windows Service. See the mongos.exe reference and MongoDB as a Windows Service and SERVER-1589 for more information.
MongoDB for Windows now supports log rotation by way of the logRotate database command. See SERVER-2612 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.
The mongooplog tool makes it possible to pull oplog entries from mongod instance and apply them to another mongod instance. You can use mongooplog to achieve point-in-time backup of a MongoDB data set. See the SERVER-3873 case and the mongooplog documentation.
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.
You can now run mongodump when connected to a secondary member of a replica set. See SERVER-3854 for more information.
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.
MongoDB extended JSON now includes a new Timestamp() type to represent the Timestamp type that MongoDB uses for timestamps in the oplog among other contexts.
This permits tools like mongooplog and mongodump to query for specific timestamps. Consider the following mongodump operation:
mongodump --db local --collection oplog.rs --query '{"ts":{"$gt":{"$timestamp" : {"t": 1344969612000, "i": 1 }}}}' --out oplog-dump
See SERVER-3483 for more information.
2.2 includes a number of changes that improve the overall quality and consistency of the user interface for the mongo shell:
The db.loadServerScripts() loads the contents of the current database’s system.js collection into the current mongo shell session. See SERVER-1651 for more information.
If you pass an array of documents to the insert() method, the mongo shell will now perform a bulk insert operation. See SERVER-3819 and SERVER-2395 for more information.
注解
For bulk inserts on sharded clusters, the getLastError command alone is insufficient to verify success. Applications should must verify the success of bulk inserts in application logic.
See the SERVER-2957 case and the documentation of the syslog run-time option or the mongod --syslog and mongos --syslog command line-options.
Added the touch command to read the data and/or indexes from a collection into memory. See: SERVER-2023 and touch for more information.
indexCounters now report actual counters that reflect index use and state. In previous versions, these data were sampled. See SERVER-5784 and indexCounters for more information.
See the documentation of the compact and the SERVER-4018 issue for more information.
The Boost library, version 1.49, is now embedded in the MongoDB code base.
If you want to build MongoDB binaries using system Boost libraries, you can pass scons using the --use-system-boost flag, as follows:
scons --use-system-boost
When building MongoDB, you can also pass scons a flag to compile MongoDB using only system libraries rather than the included versions of the libraries. For example:
scons --use-system-all
See the SERVER-3829 and SERVER-5172 issues 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.
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 索引 associated with a query to improve replication throughput in most cases. The replIndexPrefetch 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.
In 2.2 Map Reduce received the following improvements:
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.
The migration thresholds have changed in 2.2 to permit more even distribution of chunks in collections that have smaller quantities of data. See the Migration Thresholds documentation for more information.
Added License notice for Google Perftools (TCMalloc Utility). See the License Notice and the SERVER-4683 for more information.