Release Notes for MongoDB 1.8
Upgrading
MongoDB 1.8 is a standard, incremental production release and works as a drop-in replacement for MongoDB 1.6, except:
Replica set members should be upgraded in a particular order, as described in Upgrading a Replica Set.
The
mapReduce
command has changed in 1.8, causing incompatibility with previous releases.mapReduce
no longer generates temporary collections (thus,keepTemp
has been removed). Now, you must always supply a value forout
. See theout
field options in themapReduce
document. If you use MapReduce, this also likely means you need a recent version of your client driver.
Preparation
Read through all release notes before upgrading and ensure that no changes will affect your deployment.
Upgrading a Standalone mongod
Download the v1.8.x binaries from the MongoDB Download Page.
Shutdown your
mongod
instance.Replace the existing binary with the 1.8.x
mongod
binary.Restart MongoDB.
Upgrading a Replica Set
1.8.x secondaries can replicate from 1.6.x primaries.
1.6.x secondaries cannot replicate from 1.8.x primaries.
Thus, to upgrade a replica set you must replace all of your secondaries first, then the primary.
For example, suppose you have a replica set with a primary, an arbiter and several secondaries. To upgrade the set, do the following:
For the arbiter:
Shut down the arbiter.
Restart it with the 1.8.x binary from the MongoDB Download Page.
Change your config (optional) to prevent election of a new primary.
It is possible that, when you start shutting down members of the set, a new primary will be elected. To prevent this, you can give all of the secondaries a priority of
0
before upgrading, and then change them back afterwards. To do so:Record your current config. Run
rs.config()
and paste the results into a text file.Update your config so that all secondaries have priority
0
. For example:config = rs.conf() { "_id" : "foo", "version" : 3, "members" : [ { "_id" : 0, "host" : "ubuntu:27017" }, { "_id" : 1, "host" : "ubuntu:27018" }, { "_id" : 2, "host" : "ubuntu:27019", "arbiterOnly" : true } { "_id" : 3, "host" : "ubuntu:27020" }, { "_id" : 4, "host" : "ubuntu:27021" }, ] } config.version++ 3 rs.isMaster() { "setName" : "foo", "ismaster" : false, "secondary" : true, "hosts" : [ "ubuntu:27017", "ubuntu:27018" ], "arbiters" : [ "ubuntu:27019" ], "primary" : "ubuntu:27018", "ok" : 1 } // for each secondary config.members[0].priority = 0 config.members[3].priority = 0 config.members[4].priority = 0 rs.reconfig(config)
For each secondary:
Shut down the secondary.
Restart it with the 1.8.x binary from the MongoDB Download Page.
If you changed the config, change it back to its original state:
config = rs.conf() config.version++ config.members[0].priority = 1 config.members[3].priority = 1 config.members[4].priority = 1 rs.reconfig(config) Shut down the primary (the final 1.6 server), and then restart it with the 1.8.x binary from the MongoDB Download Page.
Upgrading a Sharded Cluster
Turn off the balancer:
mongo <a_mongos_hostname> use config db.settings.update({_id:"balancer"},{$set : {stopped:true}}, true) For each shard:
If the shard is a replica set, follow the directions above for Upgrading a Replica Set.
If the shard is a single
mongod
process, shut it down and then restart it with the 1.8.x binary from the MongoDB Download Page.
For each
mongos
:Shut down the
mongos
process.Restart it with the 1.8.x binary from the MongoDB Download Page.
For each config server:
Shut down the config server process.
Restart it with the 1.8.x binary from the MongoDB Download Page.
Turn on the balancer:
use config db.settings.update({_id:"balancer"},{$set : {stopped:false}})
Returning to 1.6
If for any reason you must move back to 1.6, follow the steps above in reverse. Please be careful that you have not inserted any documents larger than 4MB while running on 1.8 (where the max size has increased to 16MB). If you have you will get errors when the server tries to read those documents.
Journaling
Returning to 1.6 after using 1.8 Journaling works fine, as journaling does not change anything about the data file format. Suppose you are running 1.8.x with journaling enabled and you decide to switch back to 1.6. There are two scenarios:
If you shut down cleanly with 1.8.x, just restart with the 1.6 mongod binary.
If 1.8.x shut down uncleanly, start 1.8.x up again and let the journal files run to fix any damage (incomplete writes) that may have existed at the crash. Then shut down 1.8.x cleanly and restart with the 1.6 mongod binary.
Changes
Journaling
MongoDB now supports write-ahead Journaling to
facilitate fast crash recovery and durability in the storage engine.
With journaling enabled, a mongod
can be quickly restarted
following a crash without needing to repair the collections. An aggregation pipeline makes it possible to do
aggregation.
Sparse and Covered Indexes
Sparse Indexes are indexes that only include documents that contain the fields specified in the index. Documents missing the field will not appear in the index at all. This can significantly reduce index size for indexes of fields that contain only a subset of documents within a collection.
Covered Indexes enable MongoDB to answer queries entirely from the index when the query only selects fields that the index contains.
Incremental MapReduce Support
The mapReduce
command supports new options that enable
incrementally updating existing collections.
Previously, a MapReduce job could output either to a temporary
collection or to a named permanent collection, which it would overwrite
with new data.
You now have several options for the output of your MapReduce jobs:
You can merge MapReduce output into an existing collection. Output from the Reduce phase will replace existing keys in the output collection if it already exists. Other keys will remain in the collection.
You can now re-reduce your output with the contents of an existing collection. Each key output by the reduce phase will be reduced with the existing document in the output collection.
You can replace the existing output collection with the new results of the MapReduce job (equivalent to setting a permanent output collection in previous releases)
You can compute MapReduce inline and return results to the caller without persisting the results of the job. This is similar to the temporary collections generated in previous releases, except results are limited to 8MB.
For more information, see the out
field options in the
mapReduce
document.
Additional Changes and Enhancements
1.8.1
Sharding migrate fix when moving larger chunks.
Durability fix with background indexing.
Fixed mongos concurrency issue with many incoming connections.
1.8.0
All changes from 1.7.x series.
1.7.6
Bug fixes.
1.7.5
Extent allocation improvements.
Improved replica set connectivity for
mongos
.getLastError
improvements for sharding.
1.7.4
mongos
routesslaveOk
queries to secondaries in replica sets.New
mapReduce
output options.
1.7.3
Initial covered index support.
Distinct can use data from indexes when possible.
mapReduce
can merge or reduce results into an existing collection.mongod
tracks andmongostat
displays network usage. See mongostat.Sharding stability improvements.
1.7.2
$rename
operator allows renaming of fields in a document.db.eval()
not to block.Geo queries with sharding.
mongostat --discover
optionChunk splitting enhancements.
Replica sets network enhancements for servers behind a nat.
1.7.1
Many sharding performance enhancements.
Better support for
$elemMatch
on primitives in embedded arrays.Query optimizer enhancements on range queries.
Window service enhancements.
Replica set setup improvements.
$pull
works on primitives in arrays.
1.7.0
Sharding performance improvements for heavy insert loads.
Slave delay support for replica sets.
local.system.replset.settings.getLastErrorDefaults
for replica sets.Auto completion in the shell.
Spherical distance for geo search.
All fixes from 1.6.1 and 1.6.2.