[SERVER-6825] Hard shutdown can leave replication in unrestartable state Created: 22/Aug/12  Updated: 11/Jul/16  Resolved: 22/Aug/12

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 2.2.0-rc2, 2.3.0

Type: Bug Priority: Critical - P2
Reporter: Kristina Chodorow (Inactive) Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-7452 Add an upsert flag to the applyOps co... Closed
Operating System: ALL
Participants:

 Description   

Leading to the member fatal asserting on restart.



 Comments   
Comment by auto [ 22/Aug/12 ]

Author:

{u'date': u'2012-08-22T10:39:55-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}

Message: SERVER-6825 convert updates to upserts on oplog application

During initial sync, you must apply updates as updates and upserts as upserts,
since it is possible that an in-place update will move a document backwards and
cause the cloner to miss it. We need to detect this situation on the secondary.

However, during normal replication, we need all updates to be upserts.
Consider the situation where the oplog is replayed (possibly due to a server
crash). If an update and subsequent delete are played and then replyed,
the reply will hit an error on the update because the document will not exist.
Converting the update to an upsert will allow oplog application to proceed;
while it may result in an incomplete document, this document will be deleted
soon afterward.
Branch: v2.2
https://github.com/mongodb/mongo/commit/380b30c4843fb82e9cc378837e66b83567c16814

Comment by auto [ 22/Aug/12 ]

Author:

{u'date': u'2012-08-22T10:39:55-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}

Message: SERVER-6825 convert updates to upserts on oplog application

During initial sync, you must apply updates as updates and upserts as upserts,
since it is possible that an in-place update will move a document backwards and
cause the cloner to miss it. We need to detect this situation on the secondary.

However, during normal replication, we need all updates to be upserts.
Consider the situation where the oplog is replayed (possibly due to a server
crash). If an update and subsequent delete are played and then replyed,
the reply will hit an error on the update because the document will not exist.
Converting the update to an upsert will allow oplog application to proceed;
while it may result in an incomplete document, this document will be deleted
soon afterward.
Branch: master
https://github.com/mongodb/mongo/commit/38b899385691c1473dfd3964d026b0bdf8f77685

Comment by Eric Milkie [ 22/Aug/12 ]

If, in addition to minValid, we also had something like a maxValid value that showed how far we attempted to write operations (this would be updated when we begin a batch), we might then ignore update errors while replaying ops less than "maxValid"?

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