Mongodb – Sharded DB accidentally created during update of MongoDB from 2.4.4 to 2.6.4

mongodbsharding

I am upgrading mongo version 2.4 to 2.6
I was able to upgrade my complete cluster except one primary member of my replica set
during this period my auto running script created a sharded db.

I can not delete this db as it has important data. I wanted to confirm that i can still continue with the upgrade process for last remaining server will it create an issue.
I have completed upgrade of all mongos and config server before this.

Please let me know the impact if it will be there.

Best Answer

If all the other components are upgraded, then there will be no impact to the sharded database caused by upgrading the remaining primary. The important pieces for the sharded database/collection are mongos and the config servers rather than the individual members in this case, and you have already done that piece.

If you want to be particularly careful, you can leave the primary on 2.4, step it down and allow a 2.6 secondary to step up to primary (this would be the recommended process anyway, you should always step down a primary to secondary before you upgrade it). Doing it this way also means you have a very simple way to roll back the upgrade if necessary. Once you verify no issues, upgrade the old priamry (now secondary) and you are done.

One caveat - stepping down a primary will force close all active connections (mongos, config servers mainly) to that primary, and they will re-establish connections to the new primary once it is elected. This is expected (and necessary in fact) behavior, but can cause a brief spate of errors (for example for a long running query from that shard, which would error).

Related Solutions

Mongodb – verify that mongos server is connected to config servers

Have you tried using the sh.startBalancer() helper instead?

Rather than a straight update, it does takes an timeout argument as how long to wait for balancing to start as well as a sleep interval in terms of how long to sleep between waiting. Here's the code from the shell by way of explanation:

mongos> sh.startBalancer
function ( timeout, interval ) {
    sh.setBalancerState( true )
    sh.waitForBalancer( true, timeout, interval )
}

So, you could even break it up and use the waitForBalancer helper if you wished. For reference, here is the equivalent stopBalancer command erroring out when I tried to stop it with a config server down:

mongos> sh.stopBalancer(2000, 100)
Waiting for active hosts...
Waiting for active host adamc-mbp.local:30999 to recognize new settings... (ping : Tue Dec 31 2013 19:51:32 GMT+0000 (GMT))
Waiting for the balancer lock...
Waiting again for active hosts after balancer is off...
Tue Dec 31 19:51:39.243 error: {
    "$err" : "error creating initial database config information :: caused by :: SyncClusterConnection::udpate prepare failed:  localhost:29000:9001 socket exception [FAILED_STATE] server [localhost:29000] ",
    "code" : 8005
} at src/mongo/shell/query.js:128

Mongodb – Updating mongo sharded cluster without down time for mongod

All details are here: http://docs.mongodb.org/manual/release-notes/2.6-upgrade/

Answer 1: All metadata will get updated. I suggest to execute the mongos --upgrade using an extra mongos

Answer 2: You don't have any downtime from the config servers since mongos have the require cached information and balancer is disable

Answer 3: There is no other way. You upgrade the secondaries and then promote one of them to PRIMARY and upgrade the old-PRIMARY. Downtime is minimal (1-2 second my case) if replica set are well-sync

Best Answer

Related Solutions

Mongodb – verify that mongos server is connected to config servers

Mongodb – Updating mongo sharded cluster without down time for mongod

Related Question