Replicas keep making connections to primary

Hi all,

I have a replicaSet with two secondaries and one primary.
I want to direct all the readonly traffic to the secondaries.
I am doing this by using the readPreference=‘secondary’ or readPreference=‘secondaryPreferred’.

The clients are opened with pymongo and the url in the uri is a seed list, with the two secondaries and also the primaries.

This used to work for the last few years. All the traffic always just went to the secondaries, never received connections to the primary.

Now… something changed in the last three months, and now it looks like each connection to the secondaries produces a connection also to the primary. This really blows out the machine where the primary is hosted.

I am trying to figure out how this could have happened. The only hint is that in some applications the pymongo was bumped from 3.13.0 to 4.3.3 around that time.

Now testing locally I can see that specifying a seed list or a single instance makes a difference. But only for pymongo==3.13.0.

• with pymongo==3.13.0 - seed list → connects to primary
• with pymongo==3.13.0 - one server → NO connection to primary
• with pymongo==4.3.3 - seed list → connects to primary
• with pymongo==4.3.3 - one server → connects to primary
• with pymongo==4.3.3 - one server + directConnection=True–> NO connection to primary

So… how do I now go back to being able to give a seed list and not getting a connection to the primary? What else could have changed? How to solve?

Thanks so much for the help.

Best,
Carlo

Hi Shane,

thank you so much for your answer.

This is how we are initialising the client:

url = "secondary_1:27017,secondary2:27017,primary:27017/database"
uri = f"mongodb://{user}:{password}@{url}"
client = pymongo.MongoClient(
    uri, 
    readPreference='secondaryPreferred',
    maxPoolSize=max_pool_size, # default to 100
    socketTimeoutMS=socket_timeout, # default to 60000
    connectTimeoutMS=connect_timeout # default to 60000
)

There are sometimes thousands of simultaneous jobs running on different clusters in different sites.

I understand now the behaviour of pymongo>=4.0, and the origin of all these connections to the primary ( a lot of them ! ). Still, I am quite sure that we used to run with the same settings with pymongo==3.13.0, and never got any connection to the primary even with the seed list, but just to the two secondaries. Any idea how that could happen?

Best,
Carlo