[DOCS-2822] Comment on: "manual/tutorial/upgrade-revision.txt" Created: 28/Feb/14  Updated: 30/Oct/23  Resolved: 27/Jul/16

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Improvement Priority: Major - P3
Reporter: Ger Hartnett Assignee: Andrew Aldridge
Resolution: Won't Fix Votes: 0
Labels: collector-298ba4e7, sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Location: http://docs.mongodb.org/manual/tutorial/upgrade-revision/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36
Screen Resolution: 1280 x 800
repo: docs
source: tutorial/upgrade-revision


Participants:
Days since reply: 7 years, 29 weeks ago

 Description   

Please consider adding additional details/notes to the upgrade page. I think could be useful for some customers.

Credit: These are based on notes in a ticket written by duraid.madina@10gen.com

Upgrading the mongos query routers

For each mongos router you are running, simply stop it, upgrade it to 2.4.9, and then restart it.

NOTE - Any client applications which are connected to a mongos will have their connections closed, and they will need to be restarted if they do not contain automatic retry logic. (Most applications already have such logic, as they will need to in order to perform automatic fail-over when a server goes down.)

Upgrading the config servers

For each config server (starting with the last config server in your mongos --configdb) in turn:

  1. Stop the mongod process
  2. Upgrade its MongoDB binaries from 2.4.4 to 2.4.9
  3. Restart the mongod process
Upgrading secondaries

Upgrade each of the secondary mongod servers (and arbiters, if you have any) in every shard, as follows:

  1. First, stop one of the replica set secondaries (or arbiters). It is OK to simply shut down the server normally, but do not aggressively "kill" the servers (using e.g. kill -9.)
  2. Next, upgrade its MongoDB binaries from 2.4.4 to 2.4.9
  3. Restart it, and wait for it to re-enter the SECONDARY state
  4. Repeat this step for the next secondary, until all secondaries have been upgraded
Upgrading primaries

This time, upgrade the primary mongod server for each shard, as follows:

  1. First, stop the replica set's primary. Here, it is important to use the rs.stepDown() command, as this will ensure one of the (now upgraded) secondaries takes over the role of the primary more rapidly.
  2. Next, upgrade its MongoDB binaries from 2.4.4 to 2.4.9
  3. Restart it, and wait for it to enter the SECONDARY state. Note that while the primary was down (for you to upgrade its binaries), one of the secondaries should have automatically taken over the PRIMARY role, which is why this node will become SECONDARY.
Notes:
  • While it should not be necessary, it is possible to downgrade from 2.4.9 to 2.4.4 by following the same procedure as above.
  • It is important to note that we do not support clusters that run for extended periods of time with differing version of components. We support mixed-version clusters only for the purpose of performing live upgrades, and we encourage you to aim to complete your upgrade in a timely manner.


 Comments   
Comment by Emily Hall [ 27/Jul/16 ]

Closed for housekeeping on 7/27/2016 by Emily Hall.
If you require additional support, please open a new ticket for prioritization.
Thanks,
Emily

Generated at Thu Feb 08 07:44:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.