MongoDB.live, free & fully virtual. June 9th - 10th. Register Now

MongoDB Node driver replica set connection

Hey,

I’m using the mongodb node driver (version 3.0.6) in my server and I am having trouble with a specific use case problem that I wish to get the answer from you.

I have a replica set of 6 mongos which are sectioned to: 1 master 5 secondaries (which 3 of them are passives).

I have a node service with 4 instances of this service that connects to the replica set. Each instance is connected to a part of the replica set and not the whole set (because of a need my app requires to divided some of the DBs), the division is: I have a “core” set which includes the master and the 2 secondaries (which are not passives).

The first instance includes only the core set - and for the example shall be called “Core Instance”. The others are connected to the core set and only one of the remaining passives db (every secondary is used by an instance of my node service) - and for the example shall be called “External instance”.

I noticed that when one of the “External instances” is shutting down (because the server is shut down) the other “External instances” are having a connection error for several minutes (and after few minutes the service is working good again).

The error that is shown in the “External instances” while the shutdown is happening is:

At the docker service:
"error: MongoNetworkError: Connection 46 to {server-name} timed out
at Socket<anonymous> .../node-modules/mongodb-core/lib/connection/connection-js:258:7).
...".

At the localhost:
"Error: read ECONNRESET at tcp. on StreamRead (internal-stream_base_commons.js:167:27)".

I don’t understand why when one the “External instances” is failing the other instances are having trouble in the connection.

In my opinion, it is because of the replica set connection in the MongoClient.connect URI (is written as the documentation mentiones:
“mongodb://mongodb0.example.com:27017,mongodb1.example.com:27017,mongodb2.example.com:27017/?replicaSet=myRepl”), that it is ignoring the host list and connected to the whole replica set (or that it is working correctly but I didn’t understand the host list meaning).

My mongo version is 3.6.5 . The mongodb npm package is 3.0.10 .

*Maybe worth to mention that we are using the oplog.

Welcome to the community @bt_of,

When you include multiple hosts in a replica set connection string, the hosts are used as a seed list to discover the replica set members (and canonical host names & ports) via the replica set configuration. The seed list only determines which hosts the driver will connect to for discovering the configuration. The expected behaviour is that after successfully connecting to one of the seed list hosts and fetching the replica set configuration, the driver will attempt to connect to (and monitor) all non-hidden members of the replica set.

If you want to target read operations to a subset of your replica set, the supported approach is using read preferences with optional replica set tag sets.

If you want to connect to a specific member of your replica set without discovery and monitoring of the other replica set members, you can use a standalone connection string. However, standalone mode is a direct connection and does not support replica set failover behaviour (since you are only connected to a single MongoDB instance).

Regards,
Stennie

Hey Stennie,

First of all thank you very much, you helped me a lot!

I wanted to know if there is any option for me to see the list of the eligible members that the nearest read preference creates. (as mentioned here: https://docs.mongodb.com/manual/core/read-preference-mechanics/ in the nearest section).

Sincerely,
Tal.

Hi Tal,

The list of eligible members is evaluated for each read operation based on the requested read preference and options (for example, nearest read preference with a maxStalenessSeconds option).

I’m not sure if there is a straightforward way to log the eligible members before one is selected. You could look through the Node driver’s functional tests to see if there might be any debug or logging method for this level of detail.

If you want to target a more deterministic set of replica set members than nearest, you can add replica set tag sets to associate replica set members with user-defined tag pairs (for example, a specific use case or location). One or more tags can be used to refine targeting replica set members for secondary read preferences. See Read Preference Tag Sets in the MongoDB manual for some examples.

Regards,
Stennie