[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: SERVER-21059 always return an optime from the committed snapshot for lastVisibleOpTime metadata
Branch: master
https://github.com/mongodb/mongo/commit/54130b5a8e7f98616d325a1b4edc73fefd1b012f

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.

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