[SERVER-16706] Prevent_logOpRS from pushing primary's last optime back in time in doc-locking storage engines Created: 02/Jan/15  Updated: 15/Jan/15  Resolved: 07/Jan/15

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.8.0-rc4
Fix Version/s: 2.8.0-rc5

Type: Bug Priority: Major - P3
Reporter: Andy Schwerin Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

In storage engines that do not exclusively lock the oplog collection for the duration of a logop() operation, there is a race condition between the generation of a write's optime and recording the most recently accepted optime for the primary node via a call to ReplicationCoordiantor::setMyLastOptime().

Because all failures of logOpRS are fatal, it suffices to update the coordinator's view of the most recent optime when the optime is generated. An alternative solution that might be more correct would be to force the storage engine to update the coordinator's view of the optime when the oplog entries for the new optimes become visible. This approach may be necessary if we wish to make logOpRS failures recoverable.



 Comments   
Comment by Githook User [ 07/Jan/15 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@mongodb.com'}

Message: SERVER-16706 On primary, call setMyLastOptime when generating the new optime, to avoid data race.
Branch: master
https://github.com/mongodb/mongo/commit/e7922c24c8ac4ccfc65a005159197225fea1771e

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