Mongodb – Unable to connect to MongoDB replica set using public IPs

There are a couple of separate questions/issues here:

do you have to create that same user on nodes 2/3?

If they are members of the same replica set, then no. The users will be written to the primary and then replicated to the secondaries - remember any secondary can become primary in a normal set, so you would have to have all the data necessary to do that, including users. If the nodes are in the set when they are added, the users will replicate normally. If you add them later, they will replicate the users as part of the initial sync process.

Note that for nodes that are members of different replica sets (say multiple shards) that is not the case.

I'm having some trouble doing that if I bring up the other nodes with auth/keyfile turned on

Remember that the keyfile must be identical for all nodes in a set. The keyfile is what the nodes will use to authenticate with each other (for the purposes of initial sync and replication for a start, so it is an absolute must). If you are having issues when you add the nodes, there will be errors in the logs that will tell you why. The common reasons would be:

• Incorrect config (new nodes not configured with the replica set name)
• Different key files (this must be identical on all nodes in the replica set)
• Connectivity or hostname lookup issues

If you expand on the difficulties you have when you try to add (how you are adding, what error you get, and preferably the output of rs.status() and a sample config file) I can elaborate further.

You can follow your original strategy with a minor tweak: add Google Compute (GC) nodes into the current replica set and keep them in sync until ready to cut over. The only thing you need to change is to set those new GC nodes to have priority 0. They will be full members of the set, they just cannot be elected primary (or trigger elections).

Once you are ready to switch over to the Google nodes, you need only reset the priority to 1 (or whatever your normal values are), and then step down or remove the AWS nodes from the set. You can guarantee that a GC node is elected primary by giving them a higher priority than the AWS nodes before issuing the step down.