[SERVER-8439] Rolling upgrade process Created: 02/Feb/13  Updated: 11/Jul/16  Resolved: 18/Feb/13

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Question Priority: Minor - P4
Reporter: Jon Eisenstein Assignee: Ian Daniel
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mongo 2.2.3 (upgrading from 1.6)


Participants:

 Description   

I'm curious about how Mongo will react to a situation I'd like to perform as part of a rolling upgrade, and the documentation is somewhat unclear.

I'll be upgrading my replica set one at a time, which means each node will take several hours to catch up. I'd like to end up with my new members taking the place in DNS of the old members with minimal disruption to the set. My plan is, for each one:

1) Launch a new instance under a new hostname
2) Wait until it catches up
[Step down if primary]
3) Stop the original instance
4) Update DNS so that the new instance takes the original's place
5) Let Mongo figure out that it's properly up to date for a seamless transition
[Go on to the next one if needed]

First of all, is that a viable strategy? The original instructions we got from 10gen specified that we should shut down each server and relaunch it as the new version.

Second, would there be an issue launching all three replacements and letting them get into a replicated state so that my actual "upgrade" time is just the time for each member to figure out that it's healthy once switching each hostname in turn?

Any tips I should know about?



 Comments   
Comment by Ian Daniel [ 04/Feb/13 ]

Hi Jon,

You could take a copy of the dbpath files from one of your existing nodes, and use it seed the new node. You should shutdown the existing node before you copy the dbpath files, or do an fync+lock. This is described in our documentation here: http://docs.mongodb.org/manual/tutorial/expand-replica-set/#production-notes

Other than that, your approach looks sound.

Kind regards,
Ian

Comment by Jon Eisenstein [ 02/Feb/13 ]

I'm replacing the servers (AWS instances) with new ones that launch with the new Mongo.

Comment by Eliot Horowitz (Inactive) [ 02/Feb/13 ]

Are you trying to just upgrade mongo or also servers?
If just mongo, then on each secondary you can just take mongod down, upgrade binary, and restart.
It will only take a minute or so to catch up to replication.

Generated at Thu Feb 08 03:17:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.