2

I have a replica set with 1 secondary and 1 arbiter running version 2.6. and I would like to introduce a new member with version 3.0 so that I can upgrade the whole replica set to 3.0. I wonder if this is a way to to a "rolling upgrade" to MongoDB version 3.0?

The upgrade process I'm thinking would be:

  1. Introduce new member with version 3.0 and let it sync. With priority 0 so that it is not elected at any point.
  2. Once new SECONDARY has caught up, increase priority to make it eligible and remove old SECONDARY server.
  3. Step down PRIMARY (new member with version 3.0 becomes PRIMARY).
  4. Repeat steps 1 and 2 to remove what used to be the original PRIMARY member.

Any other upgrade process suggestions are appreciated.

Thanks

Improve this question

2 Answers 2

Reset to default
1

This is basically the rolling upgrade procedure from the docs, with the only difference being that you will temporarily be going up to a 4 member replica set based on what you have described. Hence it's basically a viable strategy if you have concerns about 3.0.

Couple of things I will note:

First, the priority zero step shows good caution but is not really gaining you anything. There is no realistic way for that node to become primary before it catches up (not considered up to date, and if the other two members fail there will not be enough votes to elect it primary with 2 out of 4). There's no harm in doing it, it just doesn't add much in a 4 member set.

The other thing that I will note is that the addition of a new set member is not actually needed. You can stop your current secondary and simply update its binaries to 3.0, restart it and it is good. Do the same for the arbiter, then step down the primary and repeat. No resync is then necessary because 3.0 is fine as a straight drop-in replacement for 2.6.

Improve this answer
1
  • Thanks Adam. I'll go ahead and do the rolling upgrade by updating the binaries without adding more replica set members. It's Ok for us have the RS running with just the PRIMARY while we are upgrading the binaries in the SECONDARY. It's unclear to me how long it would take to sync up a new replica set member, the disk usage is up to 350GB but I know that this doesn't reflect the size of the DB, which must be around 20GB after some purging done. MongoDB doesn't free up space unless you do a clean mongodump/restore, which is needed to go from 3.0 to 3.2 because of wiredtiger, so we can do it then
    – Miguel Reyes
    Commented Sep 10, 2016 at 17:15
0

As per MongoDB BOL Upgrade MongoDB to 3.0 In the general case, the upgrade from MongoDB 2.6 to 3.0 is a binary-compatible “drop-in” upgrade: shut down the mongod instances and replace them with mongod instances running 3.0. However, before you attempt any upgrade please familiarize yourself with the content of this document, particularly the procedure for upgrading sharded clusters.

If you need guidance on upgrading to 3.0, MongoDB offers consulting to help ensure a smooth transition without interruption to your MongoDB application.

You can upgrade from MongoDB 2.6 to 3.0 using a rolling upgrade to minimize downtime by upgrading the members individually while the other members are available:

There is simple three steps through which you can upgrade

Upgrade secondary members of the replica set

Upgrade the secondary members of the set one at a time by shutting down the mongod and replacing the 2.6 binary with the 3.0 binary. After upgrading a mongod instance, wait for the member to recover to SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell.

Step down the replica set primary

Use rs.stepDown() in the mongo shell to step down the primary and force the set to failover. rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.

Upgrade the primary

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 3.0 binary and start the new instance.

Replica set failover is not instant and will render the set unavailable to accept writes until the failover process completes. This may take 30 seconds or more: schedule the upgrade procedure during a scheduled maintenance window.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.