[SERVER-58586] Improve ClientCursor on mongoD to store and restore the readPreference Created: 15/Jul/21 Updated: 29/Oct/23 Resolved: 23/Aug/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Drew Paroski | Assignee: | Hana Pearlman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Query Optimization 2021-08-09, QO 2021-08-23 | ||||||||
| Participants: | |||||||||
| Description |
|
For a ClusterClientCursor on mongoS, we store the readPreference and readConcern on the cursor and restore them for getMores: https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/s/query/cluster_client_cursor_params.h#L73-L74 https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/s/query/cluster_find.cpp#L449-L451 At present, for a ClientCursor on mongoD, we only store and restore the readConcern on the cursor, but not the readPreference: We noticed this limitation when implementing The goal of this task is to update ClientCursors on mongoD to store and restore the readPreference on a cursor, and to back out the work-around in AsyncResultsMerger::_askForNextBatch() that For reference, here is the Jira ticket where the ClientCursor on mongoD was updated to store and restore the readConcern: https://jira.mongodb.org/browse/SERVER-31665 |
| Comments |
| Comment by Vivian Ge (Inactive) [ 06/Oct/21 ] |
|
Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you! |
| Comment by Githook User [ 20/Aug/21 ] |
|
Author: {'name': 'Hana Pearlman', 'email': 'hana.pearlman@mongodb.com', 'username': 'HanaPearlman'}Message: |
| Comment by Bernard Gorman [ 23/Jul/21 ] |
|
Problem here is that only the initial aggregate has a readPreference set on it, but not subsequent getMores. Since the shards don't store readPreference for the cursor, any sub-operations executed during a getMore will default to primary readPreference. Only the mongoS retains its readPreference across getMores, since we store the readPref on the cursor. It seems likely this will also be an issue for sharded $lookup. Unsure why it hasn't manifested before for $unionWith - do we establish the remote cursors during the initial "parent" aggregate, when the opCtx has the readPreference that was sent with the command from mongoS? We should probably at least consider banning readPreference on a getMore, assuming that this doesn't have driver implications, since it doesn't really make sense. |