readPreferenceTags behaviour on sharded cluster

Based on behavior observation it remains unclear how members are considered worthy. According to doc there’s latency consideration present, but it’s not clear if it’s latency between driver and mongo router or latency between primary and secondary. My issue is that when querying from a region which has one local secondary present, but primary with another secondary is in a remote region, query seems to end up randomly in both regions. If I remove the last ‘fallback’ readPreferenceTags, which allows other regions too, then I get results with expected latency.

From documentation:

Order matters when using multiple readPreferenceTags. The readPreferenceTags are tried in order until a match is found. Once found, that specification is used to find all eligible matching members and any remaining readPreferenceTags are ignored.

However, the nearest read mode, when combined with a tag set, selects the matching member with the lowest network latency. This member may be a primary or secondary.

Example of the setup:

  • secondary mongo, region a - tags something:x, region:a
  • primary mongo, region b - tags something:x, region:b
  • secondary mongo, region b - tags something:x, region:b

there’s mongos router between driver and mongo replica set, located in region:a

  1. db.getMongo().setReadPref('nearest', [ { "something": "x", "region": "a" } ])
  2. db.getMongo().setReadPref('nearest', [ { "something": "x", "region": "a" }, {"something": "x"} ])

db.getCollection('mytest').find({ _id: ObjectId("my-object-id") });

While using 1. setting, I get expected results. While using 2. setting, I can see that query is executed in random node matching second tag (as region is different)

There could be bug as the readPreferenceTags behaviour has changed in version 4.4. Part of code location has shifted and that is the reason that readPreferenceTags behavior has changed. Or there could be major changes with the code how matching is done regard with tags.

In 4.4 >

In 4.2 >