[SERVER-51835] Mongos readPreferenceTags are not working as expected Created: 26/Oct/20 Updated: 29/Oct/23 Resolved: 28/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client, Internal Code |
| Affects Version/s: | 4.4.0 |
| Fix Version/s: | 7.0.0-rc0, 4.4.20, 5.0.16, 6.0.6, 6.3.0-rc2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andres P | Assignee: | Max Hirschhorn |
| Resolution: | Fixed | Votes: | 2 |
| Labels: | sa-groomed | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Sharding NYC
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v6.3, v6.0, v5.0, v4.4
|
||||||||||||||||
| Steps To Reproduce: | Reproduce from mongo shell:
Get expected results with 1. option. While using 2. setting, I can see that query is executed in random node matching second tag. |
||||||||||||||||
| Sprint: | Sharding NYC 2023-03-06 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||
| Description |
|
From documentation:
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 |
| Comments |
| Comment by Githook User [ 16/Mar/23 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Fixes the streamable and sdam replica set monitors to obey the (cherry picked from commit 7b5b262e93af9fd3773cc842816a3517ced81e09) | ||||||||||||||||||||||
| Comment by Githook User [ 15/Mar/23 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Fixes the streamable and sdam replica set monitors to obey the (cherry picked from commit 7b5b262e93af9fd3773cc842816a3517ced81e09) | ||||||||||||||||||||||
| Comment by Githook User [ 01/Mar/23 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Fixes the streamable and sdam replica set monitors to obey the (cherry picked from commit 7b5b262e93af9fd3773cc842816a3517ced81e09) | ||||||||||||||||||||||
| Comment by Githook User [ 01/Mar/23 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Fixes the streamable and sdam replica set monitors to obey the (cherry picked from commit 7b5b262e93af9fd3773cc842816a3517ced81e09) | ||||||||||||||||||||||
| Comment by Max Hirschhorn [ 28/Feb/23 ] | ||||||||||||||||||||||
|
Many thanks for the patience regarding this ticket. It definitely sat for longer on the backlog than it ought to have. I wanted to take a moment to summarize the state across all release branches and what my plan for backporting the changes to older branches is.
We haven't found the scanning RSM to be needed as a workaround and have been satisfied by the relative stability of the streamable RSM. This is why the scanning RSM (--setParameter replicaSetMonitorProtocol=scanning) option has since been removed. And so after discussing with the Product team the plan is to -
| ||||||||||||||||||||||
| Comment by Githook User [ 27/Feb/23 ] | ||||||||||||||||||||||
|
Author: {'name': 'Max Hirschhorn', 'email': 'max.hirschhorn@mongodb.com', 'username': 'visemet'}Message: Fixes the streamable and sdam replica set monitors to obey the | ||||||||||||||||||||||
| Comment by Edwin Zhou [ 27/Oct/20 ] | ||||||||||||||||||||||
|
Hi andres.pihlak@heathmont.net, Thank you for your detailed description of your problem and your reproduction steps. I was able to reproduce your issue on a 2 node replica set. I'll These steps were taken in the mongo shell. Reproduction
Connecting to the replica set, I tested your issue on both 4.4 and 4.2. This command correctly executes a query on node_01 for both 4.4.0 and 4.2.0:
This command correctly executes a query on node_02 for both 4.4.0 and 4.2.0
This command incorrectly executes a query on node_02 for 4.4.0 but correctly executes a query on node_01 for 4.2.0
This command correctly executes a query on node_02 for both 4.4.0 and 4.2.0
The queries are seen executed in these logs, note the $readPreference: 4.4.0
node_02
4.2.0
node_02
Edwin | ||||||||||||||||||||||
| Comment by Andres P [ 27/Oct/20 ] | ||||||||||||||||||||||
|
Clarify this problem occurred with Mongo Router. To illustrate the sample infrastructure: |