[SERVER-53433] Map reduce is versioned on direct connection to shards Created: 18/Dec/20 Updated: 29/Oct/23 Resolved: 13/Apr/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 4.4.2 |
| Fix Version/s: | 4.4.7, 5.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Marcos José Grillo Ramirez | Assignee: | Eric Cox (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||
| Steps To Reproduce: | 1. Set up a replica set |
||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 24 | ||||||||||||||||
| Description |
|
After SERVER-48128 the requests sent directly to a shard should not be versioned, so, there shouldn't be any cache refresh on the node that a direct client can't retry, however, this is not the case, there is a cache refresh that's being called when executing a mapReduceWrite. Running a jstest will show that during the direct client check, there is a refresh while doing a mapReduceWithWrite. |
| Comments |
| Comment by Githook User [ 10/May/21 ] | |||||||||||
|
Author: {'name': 'Eric Cox', 'email': 'eric.cox@mongodb.com', 'username': 'ericox'}Message: (cherry picked from commit 513af98cb33e736d885a2a1b159685c335492cf0) | |||||||||||
| Comment by Githook User [ 13/Apr/21 ] | |||||||||||
|
Author: {'name': 'Eric Cox', 'email': 'eric.cox@mongodb.com', 'username': 'ericox'}Message: | |||||||||||
| Comment by Eric Cox (Inactive) [ 12/Feb/21 ] | |||||||||||
|
bernard.gorman I think I was able to reproduce this using these steps, does this make sense? 1.) Start a single node replSet for the shard nodes,
connect to this node with the mongo shell, and run rs.initiate() 2.) Start a single node replSet for a config server,
connect to this node with the mongo shell, and run rs.initiate() 3.) start a mongos connected to the config server replSet cfg0
4.) connect to mongos with the mongo shell and shard a database, and shard some collection "mrfoo".
5.) insert data through mongos
6.) Stop mongo shell and directly connect to the shard server mongod at localhost:27018. Run a map reduce job,
This should run fine. Now to reproduce the db refresh error, we will:
The error that I'm seeing is:
| |||||||||||
| Comment by Eric Cox (Inactive) [ 04/Feb/21 ] | |||||||||||
|
I took another look at this. The main problem that was pointed out above is that a mapReduce command is versioned via a direct client connection which triggers a refresh here. The call to getCollectionOptions() during the mapReduce with an out parameter is invoked in DocumentSourceOut. Unfortunately, I still haven't been able to reproduce the failure linked in BF-19541 I essentially did the following to try to reproduce.
After speaking with marcos.grillo and bernard.gorman, who discussed the changes in Speaking to Bernard we discussed one possible way to do this is to rework the ShardServerProcessInterface methods to avoid using the cache completely if !_opIsVersioned his might entail some changes to _versionCommandIfAppropriate. Another idea may be to call a superclass method like CommonMongoProcessInterface::<methodName> if the parent op isn't versioned. |