Issue with MongoDB Read Preference Tags Not Enforced Strictly

MongoDB Atlas Atlas Search
,
1

I’m encountering an unexpected behavior with MongoDB’s read preference tags where read operations are being served from replica set members that do not match the specified tag sets or no any tags present.

Here are the details:

Environment:

MongoDB version: 6.0.1
Deployment type: Replica set
Number of replica set members: 3
Deployment configuration: replica set

Use Case:
I am attempting to utilize a dedicated replica for a specific operation while also implementing a fallback mechanism.

The desired behavior is as follows:
Specify read preference tags to route a specific operation to a dedicated replica.
If the dedicated replica is unavailable, fallback to any available node from the common replicas.

Steps to Reproduce:

Configure a MongoDB replica set with multiple members.
Specify read preference tags in the MongoDB URI, for example:

URI = mongodb://test_db:read_db!2017@server_1:27017,server_2:27017,server_3:27017/db?replicaSet=re_test_db_set&readPreference=secondaryPreferred&readPreferenceTags=use:dedicatedReplica

Perform read operations against the replica set.
Expected Behavior:

I expect MongoDB to strictly enforce the specified read preference tags and only serve read operations from replica set members that match the specified tag sets. If no members match the criteria, I expect MongoDB to return an error indicating that no suitable members were found.

Actual Behavior:

Despite specifying read preference tags in the URI, MongoDB returns data even if no replica set members match the specified tag sets. It appears that MongoDB is prioritizing performance and availability over strict adherence to read preference tags.

Questions:

Is this behavior expected or documented behavior in MongoDB?
Is there a way to enforce strict adherence to read preference tags, such that MongoDB returns an error if no suitable members are found?
Are there any best practices or recommendations for ensuring that read preference tags are enforced strictly in a replica set deployment?

Conclusion:
I would appreciate any insights, recommendations, or guidance on how to address this issue and ensure that MongoDB strictly enforces read preference tags according to the specified criteria.

Thank you for your assistance!

2

It all depends on your configuration. As per documentation:

If no members match any of the tag sets, the read operation returns with an error.

but

To avoid an error if no members match any of the tag specifications, you can add an empty document { } as the last element of the tag set list to read from any eligible member.

3

According to the documentation, when attempting to connect to a database using tag sets without configuring any tag sets, an error should be raised. However, in my case, no error is raised even though no tag sets have been configured.
Below mongo uri, i am using:
URI = mongodb://test_db:read_db!2017@server_1:27017,server_2:27017,server_3:27017/db?replicaSet=re_test_db_set&readPreference=secondaryPreferred&readPreferenceTags=use:dedicatedReplica

4

Wow. I am really sorry that I misunderstood your issue that much. I would never have thought that anyone would try to use read preference tags without configuring tag sets in the replica set. I really missed the following from the original post:

May be you should update the part Steps to Reproduce from your post to mentioned that the replica set has no tag sets configured. I was, and most likely everyone was under the impression that your replica set had tag sets configured. What would be the point of trying read preference tags if the server has none configured?

Your issue is an edge case where you trying to use a feature while not doing the proper configuration for the feature. It is a non issue for me. Sorry if I pointed you to documentation that is not helpful for your use-case.

Some of your sentences should be updated to make it clear that your are not configuring any tag sets in your replica set.

The only one I can make is that if you want to use read preference tags in your URI make sure that you configure your replica set with read preference tag sets.

Sorry if I we all waste our time on this issue.