[SERVER-21059] Need to ensure that we never update the ShardRegistry's config OpTime to a visible but uncommitted OpTime Created: 21/Oct/15 Updated: 10/Nov/15 Resolved: 23/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.2.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Minor Change |
| Operating System: | ALL |
| Sprint: | Repl B (10/30/15) |
| Participants: |
| Description |
|
There are at least two cases where we run a command against a config server without including a read concern (here and here. If we don't include the 'majority' read concern, then we'll automatically update our config server optime to the returned 'visible' level, which will not be committed since we didn't query against the committed snapshot. This could potentially cause future config server operations to hang waiting for the visible optime to become committed, if it never does. |
| Comments |
| Comment by Eric Milkie [ 23/Oct/15 ] |
|
lastVisibleOpTime field now represents the last optime in the current committed snapshot, regardless of the readConcern used. |
| Comment by Githook User [ 23/Oct/15 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Spencer Brody (Inactive) [ 21/Oct/15 ] |
|
This should be easily fixable for the user management read commands, but is tricky for fixing the running of serverStatus since serverStatus doesn't accept a read concern. |