Release Notes for MongoDB 1.8

Upgrading

MongoDB 1.8 is a standard, incremental production release and works asa drop-in replacement for MongoDB 1.6, except:

  • Replica set members should be upgraded in aparticular order, as described in Upgrading a Replica Set.
  • The mapReduce command has changed in 1.8, causingincompatibility with previous releases. mapReduce nolonger generates temporary collections (thus, keepTemp has beenremoved). Now, you must always supply a value for out. See theout field options in the mapReduce document. If youuse MapReduce, this also likely means you need a recent version ofyour client driver.

Preparation

Read through all release notes before upgrading and ensure that nochanges will affect your deployment.

Upgrading a Standalone mongod

Upgrading a Replica Set

1.8.x secondariescan replicate from 1.6.xprimaries.

1.6.x secondaries cannot replicate from 1.8.x primaries.

Thus, to upgrade a replica set you must replace all of yoursecondaries first, then the primary.

For example, suppose you have a replica set with a primary, anarbiter and several secondaries. To upgrade the set, do thefollowing:

  • For the arbiter:

  • 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 giveall of the secondaries a priority of 0 beforeupgrading, and then change them back afterwards. To do so:

  • Record your current config. Run rs.config() and paste theresults into a text file.

  • Update your config so that all secondaries havepriority 0. For example:

  1. config = rs.conf()
  2. {
  3.      "_id" : "foo",
  4.      "version" : 3,
  5.      "members" : [
  6.              {
  7.                      "_id" : 0,
  8.                      "host" : "ubuntu:27017"
  9.              },
  10.              {
  11.                      "_id" : 1,
  12.                      "host" : "ubuntu:27018"
  13.              },
  14.              {
  15.                      "_id" : 2,
  16.                      "host" : "ubuntu:27019",
  17.                      "arbiterOnly" : true
  18.              }
  19.              {
  20.                      "_id" : 3,
  21.                      "host" : "ubuntu:27020"
  22.              },
  23.              {
  24.                      "_id" : 4,
  25.                      "host" : "ubuntu:27021"
  26.              },
  27.      ]
  28. }
  29. config.version++
  30. 3
  31. rs.isMaster()
  32. {
  33.      "setName" : "foo",
  34.      "ismaster" : false,
  35.      "secondary" : true,
  36.      "hosts" : [
  37.              "ubuntu:27017",
  38.              "ubuntu:27018"
  39.      ],
  40.      "arbiters" : [
  41.              "ubuntu:27019"
  42.      ],
  43.      "primary" : "ubuntu:27018",
  44.      "ok" : 1
  45. }
  46. // for each secondary
  47. config.members[0].priority = 0
  48. config.members[3].priority = 0
  49. config.members[4].priority = 0
  50. rs.reconfig(config)

  • For each secondary:

  • If you changed the config, change it back to its original state:
  1. config = rs.conf()
  2. config.version++
  3. config.members[0].priority = 1
  4. config.members[3].priority = 1
  5. config.members[4].priority = 1
  6. rs.reconfig(config)
  • Shut down the primary (the final 1.6 server), and then restart itwith the 1.8.x binary from the MongoDB Download Page.

Upgrading a Sharded Cluster

  • Turn off the balancer:
  1. mongo <a_mongos_hostname>
  2. use config
  3. db.settings.update({_id:"balancer"},{$set : {stopped:true}}, true)
  1. use config
  2. 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 inreverse. Please be careful that you have not inserted any documentslarger than 4MB while running on 1.8 (where the max size has increasedto 16MB). If you have you will get errors when the server tries to readthose documents.

Journaling

Returning to 1.6 after using 1.8Journaling worksfine, as journaling does not change anything about the data file format.Suppose you are running 1.8.x with journaling enabled and you decide toswitch back to 1.6. There are two scenarios:

  • If you shut down cleanly with 1.8.x, just restart with the 1.6 mongodbinary.
  • If 1.8.x shut down uncleanly, start 1.8.x up again and let the journalfiles run to fix any damage (incomplete writes) that may have existedat the crash. Then shut down 1.8.x cleanly and restart with the 1.6mongod binary.

Changes

Journaling

MongoDB now supports write-ahead Journaling tofacilitate fast crash recovery and durability in the storage engine.With journaling enabled, a mongod can be quickly restartedfollowing a crash without needing to repair the collections. The aggregation framework makes it possible to doaggregation

Sparse and Covered Indexes

Sparse Indexes are indexes that only includedocuments that contain the fields specified in the index. Documentsmissing the field will not appear in the index at all. This cansignificantly reduce index size for indexes of fields that contain only asubset of documents within a collection.

Covered Indexes enable MongoDB to answerqueries entirely from the index when the query only selects fieldsthat the index contains.

Incremental MapReduce Support

The mapReduce command supports new options that enableincrementally updating existing collections.Previously, a MapReduce job could output either to a temporarycollection or to a named permanent collection, which it would overwritewith new data.

You now have several options for the output of your MapReduce jobs:

  • You can merge MapReduce output into an existing collection. Outputfrom the Reduce phase will replace existing keys in the outputcollection if it already exists. Other keys will remain in thecollection.
  • You can now re-reduce your output with the contents of an existingcollection. Each key output by the reduce phase will be reduced withthe existing document in the output collection.
  • You can replace the existing output collection with the new results ofthe MapReduce job (equivalent to setting a permanent outputcollection in previous releases)
  • You can compute MapReduce inline and return results to the callerwithout persisting the results of the job. This is similar to thetemporary collections generated in previous releases, except resultsare limited to 8MB.

For more information, see the out field options in themapReduce 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

1.7.4

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 and mongostat 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 option
  • Chunk 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.
  • getLastErrorDefaults for replica sets.
  • Auto completion in the shell.
  • Spherical distance for geo search.
  • All fixes from 1.6.1 and 1.6.2.

Release Announcement Forum Pages

Resources