Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
4.4.0
-
Sharding NYC
-
Fully Compatible
-
ALL
-
v6.3, v6.0, v5.0, v4.4
-
-
Sharding NYC 2023-03-06
-
(copied to CRM)
Description
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.
This isn't true in 4.4 anymore when using multiple readPreferenceTags as a fallback.Â
Seems part of code location has shifted and that is the reason that readPreferenceTags behavior has changed. Or there could be other major changes with the code how matching is done regard with tags.
In 4.4 >
https://github.com/mongodb/mongo/blob/v4.4/src/mongo/client/scanning_replica_set_monitor.cpp#L1236-L1250Â
In 4.2 >
https://github.com/mongodb/mongo/blob/v4.2/src/mongo/client/replica_set_monitor.cpp#L1149Â
Attachments
Issue Links
- is related to
-
SERVER-41910 Make RSM::getMatchingHosts return multiple hosts in the presence of tags
-
- Closed
-
- related to
-
DRIVERS-2563 Add spec test which checks that the order of read preference tag matching is obeyed
-
- Backlog
-