2

We are managing two distinct Mongo replicasets, one for staging, one for production, running on Kubernetes. Networking is provided via Kubernetes' internal infrastructure, such so that Mongo servers on each cluster are available at:

  • mongo-0.mongodb-service.default.svc.cluster.local:27017
  • mongo-1.mongodb-service.default.svc.cluster.local:27017
  • mongo-2.mongodb-service.default.svc.cluster.local:27017 ,...etc

We need to use mongoexport / mongoimport to copy data from the staging cluster to prod. Clients on the staging cluster can use an SSH bridge to access the private network on the production cluster, so we set up a bridge:

ssh -L 27020:mongo-0.mongodb-service.default.svc.cluster.local:27017 [..]

Then do mongoexport locally, and run mongoimport against localhost:27020.

Problem: Mongo load balances the primary (writable) master. So, when mongoexport connects to mongo-0, it is being told to connect to mongo-1.

So, hey, we just set up 3 port forwarding, right?

ssh -L 27020:mongo-0.mongodb-service.default.svc.cluster.local:27017 -L 27021:mongo-1.mongodb-service.default.svc.cluster.local:27017 -L 27022:mongo-2.mongodb-service.default.svc.cluster.local:27017 [...]

mongoimport --host rs0/localhost:27020,localhost:27021,localhost:27022 [..]

Well, no. At this point, Mongo-0 on the remote cluster tells mongoimport to connect to Mongo-1, which it does so on the local cluster (and fails at authentication, because different username / password).

Question: In what way might we transfer data from one replicaset to another when remote connection has to go through SSH bridging?

Thank you!

Community
  • 1
  • 1
Silver Dragon
  • 5,480
  • 6
  • 41
  • 73
  • I strongly suggest that you do not use mongoexport/mongoimport as that could result in the loss of type fidelity, e.g. Dates, ObjectIds will not be translated properly. You should instead use mongodump/mongorestore. Regarding your issue, does it work if you use just the host of the primary, e.g. not use a replica set connection? – helmy Dec 07 '17 at 05:47
  • Yep, we're using mongodump / mongorestore for this! – Silver Dragon Dec 08 '17 at 06:31
  • Re: issue, if we're accessing just the primary, it works perfectly; however, the issue is we can't predict in advance which of the 3 is going to be the primary -this being Kubernetes, mongos get reshuffled occasionally. If, however, eg one could query from any arbitrary mongos which the server is from bash, we could connect to mongo-0, get primary, and bridge to that indeed. Is this possible? – Silver Dragon Dec 08 '17 at 06:32
  • I think that should work, I've done something similar in the past. – helmy Dec 08 '17 at 10:28
  • The other thing is, why not just do the dump via the mongos rather than connecting to the replica set? You have to be careful when you bypass mongos, you could see orphaned chunks or in-progress migrations. – helmy Dec 08 '17 at 15:06

0 Answers0