How do I change IP's of shard servers

[Avery Fay]

We're currently moving hardware from one datacenter to another. Up to now, we've been using purely internal IP"s. We'd like to move our sharded stuff over a number of days which would require us to start using external IP's for everything so that they would be available to both datacenters. How would we go up changing all the IP's?

Thanks,

Avery

[Eliot Horowitz]

What mongo version are you running and are you using replica sets?

If you're using 1.8 and replica sets, all you have to do is add new
nodes to the replica sets (can do one at a time) and then remove the
old ones.

The config servers entries for those shards will be updated automatically.

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.
>

[gumby]

# Sorry for the double-post, somewhat new to google groups

I've been testing a shard cluster (mongodb v 1.8.0) without replica
sets, running on EC2. After stopping and starting shard instances,
they are assigned new hostnames/internal IPs. To bring up a shard
cluster from a "stopped" state, I've been manually updating my config
db's "shards" collection "host" values to reflect the new shards'
internal IPs. This seems to work but I'm curious if it risks
corrupting the cluster, or other unknown downsides? (Obviously this
isn't a solution for a production cluster)

Thanks,
- Ryan

[Avery Fay]

We're still on a 1.6.6-pre release. Unfortunately, due to a mishandled deployment, we have some older nodes that aren't members of a replica set, but most nodes are.

I don't think either case is particularly easy to handle though. For the replica sets, we have to completely cycle out the current nodes because the replica set definition is using internal IP's. We can't add a new node in a different datacenter until all current members use external IP's. It would be a whole lot easier if we could just bring them down real quick and then just run an update command that would change IP's everywhere they need to be changed.

You're right that it's worse for the non replica nodes. I guess we'll have to completely remove them from the sharding cluster after migrating all data off?

BTW, why would we need 1.8 to add new nodes to a sharded replica set? I thought that was completely supported in the 1.6 tree.

Avery

[Eliot Horowitz]

> I don't think either case is particularly easy to handle though. For the
> replica sets, we have to completely cycle out the current nodes because the
> replica set definition is using internal IP's. We can't add a new node in a
> different datacenter until all current members use external IP's. It would
> be a whole lot easier if we could just bring them down real quick and then
> just run an update command that would change IP's everywhere they need to be
> changed.

You can use --fastsync to change the ip quickly.

> You're right that it's worse for the non replica nodes. I guess we'll have
> to completely remove them from the sharding cluster after migrating all data
> off?

Or just convert them to replica sets

> BTW, why would we need 1.8 to add new nodes to a sharded replica set? I
> thought that was completely supported in the 1.6 tree.

The difference is that in 1.8 mongos automatically updates the config
server with the most current replica set config, so its a bit simpler.