[SERVER-28808] (v3.2) applyChunkOpsDeprecated should do a write before trying to confirm the migration commit (applyOps) succeeded despite errors Created: 14/Apr/17 Updated: 29/Jan/18 Resolved: 08/May/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Sharding 2017-05-08, Sharding 2017-05-29 | ||||||||
| Participants: | |||||||||
| Description |
|
BF-5149 (v3.2 failure) is an fassert in the migration critical section, where the shard cannot tell whether the commit was successful or not. This is because it tries to check whether the applyOps succeeded or not by doing a followup query. However, this query can be sent to secondaries, and the shard does not always have the latest config opTime to make sure what is seen on the secondary is the latest information. v3.4 changes the behavior by trying to do a successful write to the config primary, so as the acquire the latest config opTime, before sending the query that can target secondaries. We could add the same thing to v3.2. This solution doesn't cover all edge cases. For v3.6, we intend to do |
| Comments |
| Comment by Dianna Hohensee (Inactive) [ 08/May/17 ] |
|
Closing as won't fix. The dependent BFs have been marked as trivial. Any new related v3.2 BFs should be marked as trivial as well. |
| Comment by Kaloian Manassiev [ 18/Apr/17 ] |
|
Since it is only 3.2 we won't fix it. Assigning to Dianna to close and figure out what to do with the build failures. |