[SERVER-55603] Shell read preference behavior is wrong for currentOp Created: 29/Mar/21  Updated: 27/Oct/23  Resolved: 07/May/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: Katherine Wu (Inactive)
Resolution: Gone away Votes: 0
Labels: greenerbuild
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-47603 Rewrite db.currentOp() shell helper i... Closed
Operating System: ALL
Participants:
Linked BF Score: 75

 Description   

First, let's start a two shard cluster where each shard is a two-node replica set:

var st = new ShardingTest({shards: 2, rs: {nodes: 2}, mongos: 1});

This should result in shardsvr primaries running on ports 20000 and 20002, shardsvr secondaries running on 20001 and 20003, and a mongos running on 20007. Connecting to the mongos "admin" database, we have three ways of running a currentOp:

  1. Directly run the currentOp command, using db.runCommand({currentOp: 1}).
  2. Use a $currentOp pipeline, db.aggregate([\{$currentOp: {}}]).
  3. Use the shell helper, db.currentOp().

Problem #1: While methods (1) and (2) will target the primaries on 20000 and 20002 as expected, the shell helper method (3) will target the secondaries on 20001 and 20003. I can see from the logs that the shell is sending readPreference mode "secondaryPreferred" to the server, which is not correct.

Problem #2: If I use the shell to set a "primaryPreferred" readPreference on the session, now both methods (2) and (3) erroneously target the secondary nodes. For example,

MongoDB Enterprise mongos> db.getSession().getOptions().setReadPreference("primaryPreferred")
MongoDB Enterprise mongos> db.aggregate([{$currentOp: {}}, {$group: {_id: "$host", count: {$sum: 1}}}]).pretty()
{ "_id" : "storchbox:20001", "count" : 16 }
{ "_id" : "storchbox:20003", "count" : 16 }

I can see from the logs that this operation sends a readPreference of "secondaryPreferred" to mongos, even though the readPreference configured in the shell is "primaryPreferred".

Problem #3: We should clarify what is supposed to happen when causal consistency is enabled via db.getMongo().setCausalConsistency(). At the moment, methods (1) and (2) will continue to target the primary nodes, but (3) will target the secondaries. This seems likely related to the other observations above, but I wanted to mention it explicitly so test authors know how to handle passthrough suites relying on causal consistency when the test uses currentOp.



 Comments   
Comment by Katherine Wu (Inactive) [ 07/May/21 ]

Fixed as part of SERVER-47603.

Comment by David Storch [ 31/Mar/21 ]

The fix from SERVER-47603 has been reverted, so the linked build failure is now resolved as well. During triage of this ticket, we should decide between simply closing this ticket as "Won't Do", or looking into whether read preference / causal consistency is implemented correctly in the shell for the $currentOp agg stage and the db.currentOp() helper.

Comment by David Storch [ 29/Mar/21 ]

I believe that some of this behavior was introduced as part of SERVER-47603. I think we should likely revert SERVER-47603 as discussed elsewhere. That should resolve the linked build failure. Once the revert is done we should address this ticket, and check whether the problems around currentOp host targeting have gone away

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