[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:
Related
related to SERVER-59499 Consider banning read preference on a... Backlog
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:

https://github.com/mongodb/mongo/blob/e5c7116913d04d66eb1c9d5cc15250167c37e2c3/src/mongo/db/commands/getmore_cmd.cpp#L226

We noticed this limitation when implementing SERVER-55309 . We were able to work around this limitation in short term by changing AsyncResultsMerger::_askForNextBatch() to manually add the readPreference to the 'getmore' command before it sends the getmore command to the remote machine, but this was not the ideal fix to the underlying issue:

https://github.com/mongodb/mongo/blob/50315039df4c36d9cde809eaaf56c439ee767340/src/mongo/s/query/async_results_merger.cpp#L452

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 SERVER-55309 introduced.

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: SERVER-58586: Improve ClientCursor on mongoD to store and restore the…
Branch: master
https://github.com/mongodb/mongo/commit/c3af4467a404fffebd8b8584fc8c24160d02e850

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.

Generated at Thu Feb 08 05:44:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.