[SERVER-47910] mongo shell - Mongo() connects to wrong replica set when it has the same name Created: 03/May/20  Updated: 08/Jan/24  Resolved: 19/Jun/23

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 4.2.6
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Spencer Brown Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 1
Labels: sdp-backlog-purge
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Server Development Platform
Participants:
Case:

 Description   

If you have two replica sets with the same name, and you login to replica set 1 then make a new connection to replica set 2 with the Mongo() function, the connection actually goes to replica set 1 when you use it.

For the issue to manifest, you must have two replica sets with the same replica set name, connect to them as replica sets not as individual hosts, and the SSL modes must be the same. We used MongoDB version 4.2.6, but we suspect this issue exists in earlier versions as well.

In the repro below, all members are on the same host, the first replica set is on ports 27017/8/9, and the second is on ports 27027/8/9. A document is added to test.foo to identify the replica set.

Start mongo shell on replica set 2 and show data:

$ mongo "mongodb://admin:REDACT@mongodb-local.computer:27027/test?ssl=true&authSource=admin&replicaSet=m" --sslCAFile tls-certs/public-ca.pem --ssl
...
MongoDB Enterprise m:PRIMARY> rs.conf().members[0].host
mongodb-local.computer:27027
MongoDB Enterprise m:PRIMARY> db
test
MongoDB Enterprise m:PRIMARY> db.foo.find()
{ "_id" : ObjectId("5eac34b18a34c540e6aef514"), "a" : "this is replica set 2" }

Start mongo shell on replica set 1 and show data. Create new connection to replica set 2. When you use the connection to show data, it goes to replica set 1, which is the issue being reported here.

$ mongo "mongodb://admin:REDACT@mongodb-local.computer:27017/test?ssl=true&authSource=admin&replicaSet=m" --sslCAFile tls-certs/public-ca.pem --ssl
...
MongoDB Enterprise m:PRIMARY> rs.conf().members[0].host
mongodb-local.computer:27017
MongoDB Enterprise m:PRIMARY> db
test
MongoDB Enterprise m:PRIMARY> db.foo.find()
{ "_id" : ObjectId("5eac34f76790a129bd1430d3"), "a" : "this is replica set 1" }
MongoDB Enterprise m:PRIMARY> shouldbe2 = new Mongo('mongodb://admin:REDACT@mongodb-local.computer:27027/test?replicaSet=m&authSource=admin&ssl=true');
connection to m/mongodb-local.computer:27027
MongoDB Enterprise m:PRIMARY> shouldbe2.getDB('test').foo.find();
{ "_id" : ObjectId("5eac34f76790a129bd1430d3"), "a" : "this is replica set 1" }
MongoDB Enterprise m:PRIMARY>



 Comments   
Comment by Alex Neben [ 19/Jun/23 ]

This has been identified as work that the SDP team won't do in the near term. Please reopen with a comment if you feel this work should be reprioritized and explain why.

Comment by Steven Vannelli [ 10/May/22 ]

Moving this ticket to the Backlog and removing the "Backlog" fixVersion as per our latest policy for using fixVersions.

Comment by Andy Schwerin [ 05/May/20 ]

steve_hand@ultimatesoftware.com, the Mongo object in the shell is a thin veneer over a different concept that the server uses for managing pools of connections to nodes in various shards. It is not its own connection pool or logical connection object as it is in drivers.

Comment by Steve Hand [ 05/May/20 ]

I'm not sure what mental overhead would be required. Each Mongo object was created with a connection string, including the servers involved in that connection. Presumably, behind the scenes, there are in fact two connections. It seems like a bug that the shell cannot distinguish between the two objects given a reference to one of them.

Comment by Mira Carey [ 05/May/20 ]

I think this is an area where it makes sense to have different behavior inside of the server and outside. For drivers, it makes perfect sense to support contacting multiple replica sets with the same name, because driver's are already in the position of contacting unrelated clusters and there's little need to enforce extra pooling of resources/work beyond the uri used for a particular client object.

For inside the server though, we save ourselves a lot of mental overhead by assuming that nodes only talk to nodes in the same cluster and we do get some benefit for being able to use replica set names as unique identifiers (perhaps that shouldn't be the case, but it is so in sharding today). So we'd bear real costs outside just the RSM to make this happen in the server today. It's also not as easy as having multiple ReplicaSetMonitorManagers, because we rely on global hooks to force monitoring updates in our existing testing (that'd be an additional layer of interdependence)

All of which makes me lean in the direction of: "let the current shell be slightly surprising, and a slightly poor implementation" and continue to wait on the next generation shell.

Comment by Andy Schwerin [ 05/May/20 ]

I think I agree with your, Bernie, but I'm not sure we'll ever fix it in the legacy shell. At least the team will now have the information they need to make a decision.

Comment by Bernie Hackett [ 05/May/20 ]

It seems to me that calling "new Mongo" with a connection string listing a specific set of hosts should give you a new Mongo connected to that set of hosts, assuming the setname is correct, not the set for the Mongo instance implicitly created when the shell was executed. Drivers use setname to ensure the list of hosts you specified actually matches that setname for all hosts. They don't use setname to make assumptions about what list of hosts you meant. Giving all your replica sets the same name defeats the purpose of the setname check in drivers.

Comment by Spencer Brown [ 05/May/20 ]

I was able to reproduce this behavior on version 3.4.24.

Comment by Andy Schwerin [ 05/May/20 ]

Hmmm... The server's implementation of monitoring has always required unique set names, because it is possible for all the host names in a set to change. The shell uses the server's implementation. behackett and mira.carey@mongodb.com, any comments? I guess this might be a "won't fix" rather than "works as design", with the justification being that the new mongo shell is where we're focusing development effort?

Comment by Spencer Brown [ 05/May/20 ]

Reviewing the Server Discovery and Monitoring spec, they refer to a TopologyDescription data structure with a setName field containing the replica set name, but there appears to be no specification that replica set names must be unique across monitored topologies.

Comment by Steve Hand [ 04/May/20 ]

However, other drivers, like 'pymongo' do not have this problem. 

Comment by Andy Schwerin [ 04/May/20 ]

This might be "as designed". A replica set is considered identified by the set name, not the list of hosts.

Comment by Steve Hand [ 04/May/20 ]

This problem was originally found on DB version 4.0.13-7. 

Generated at Thu Feb 08 05:15:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.