[SERVER-36701] Concurrent mapReduce replace with setFCV between 3.4 and 3.6 can cause errors with UUID assignment/removal Created: 16/Aug/18  Updated: 06/Dec/22  Resolved: 16/Mar/20

Status: Closed
Project: Core Server
Component/s: MapReduce, Upgrade/Downgrade
Affects Version/s: 3.6.6
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Maria van Keulen Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-36447 [3.6] MapReduce uses the output colle... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Participants:
Linked BF Score: 54

 Description   

Running a concurrency workload with setFCV toggling between 3.4 and 3.6 and mapReduce replace may cause collection validation to fail the UUID checks.



 Comments   
Comment by Connie Chen [ 16/Mar/20 ]

We won't fix this since its on a stable branch that will be retired soon

Comment by Maria van Keulen [ 17/Aug/18 ]

esha.maharishi I believe this issue is distinct from SERVER-36447, since SERVER-36447 has to do with reusing UUIDs during collection creation. SERVER-36701 refers to an issue where a collection has already been created but fails to get assigned a UUID during the UUID assignment procedure.

Comment by Ian Whalen (Inactive) [ 17/Aug/18 ]

maria.vankeulen to rerun the repro script with $out to see if there could be a similar issue there.

Comment by Ian Whalen (Inactive) [ 17/Aug/18 ]

For 3.6 we will disallow setFCV from running concurrently with all mapreduce "replace".

Comment by Esha Maharishi (Inactive) [ 17/Aug/18 ]

maria.vankeulen, does this have the same root cause as SERVER-36447?

Generated at Thu Feb 08 04:43:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.