Upgrading to 1.8

First, upgrade your shell (mongo) to the 1.8.x shell.

Upgrading Replica Sets

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

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

Thus, the trick is to replace all of your secondaries, then the primary.

For example, suppose we have a typical replica set with 1 primary, 1 secondary, and 1 arbiter. To upgrade this set, do the following:

1. For each arbiter:
   • Shut down the arbiter
   • Start it back up with the 1.8 binary
2. Change your config (optional)
   It is possible that, when you start shutting down members of the set, a new primary will be elected. If you wish to prevent this, you can give all of the slaves a priority of 0 before upgrading, then change them back afterwards.
   • Record your current config. Run rs.conf() 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 slave
     > config.members[0].priority = 0
     > config.members[3].priority = 0
     > config.members[4].priority = 0
     > rs.reconfig(config)
     

3. For each slave:
   • Shut down the slave
   • Start it back up with the 1.8 binary
4. 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)
   

5. Shut down the primary (the final 1.6 server) and restart it with the 1.8 binary.

Upgrading Sharded Clusters

1. Turn off the balancer:

   $ mongo <a_mongos_hostname>
   > use config
   > db.settings.update({_id:"balancer"},{$set : {stopped:true}}, true)
   

2. For each shard:
   • If the shard is a replica set, follow the directions above for replica sets.
   • If the shard is a single mongod process, shut it down and start it back up with the 1.8 binary.
3. For each mongos:
   • Shut down the mongos process
   • Restart with the 1.8 binary
4. For each config server:
   • Shut down the config server process
   • Restart with the 1.8 binary
5. Turn on the balancer

   > use config
   > db.settings.update({_id:"balancer"},{$set : {stopped:false}})
   

Returning to 1.6

If something goes wrong and you wish to 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.0 with journaling enabled and something isn't working for you, so you decide to switch back to 1.6. There are two scenarios:

1. If you shut down cleanly with 1.8.x, just restart with the 1.6 mongod binary.
2. 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.0 cleanly and restart with the 1.6 mongod binary.

See Also

• 1.8 Release Notes page for details on changes in v1.8 to map/reduce.

Download

• Download v1.8