Details
-
Bug
-
Resolution: Done
-
Major - P3
-
2.4.9, 2.5.5
-
None
-
ALL
-
Description
If the primary steps down while in the middle of a multi-update, the operation may continue to update documents until it first attempts to log the op to the oplog. At that point, the logOp() will fail, but the database is inconsistent. The database will contain the last update, but it won't appear in the oplog, and so will not replicate. It also won't get rolled back when the new primary takes writes, because there's no trace of it in the oplog.
A minimal option would be to make the current massert() on this condition an fassert(), to eliminate corruption.
Later, it will be necessary to audit all insert, update and remove paths (legacy and write command) to ensure that they validate primary-ness after recovering from yields.
Attachments
Issue Links
- is related to
-
SERVER-12749 write commands fail to check replica set master
-
- Closed
-