-
Type: Bug
-
Resolution: Done
-
Priority: Blocker - P1
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
v3.2
-
Integrate+Tuning 14 (05/13/16), Integrate+Tuning 15 (06/03/16), Integrate+Tuning 16 (06/24/16)
Currently we break some guarantees of atomicity by using separate WUOWs for each op and for the final logOp. This can result in a server performing the modification but not adding it to its oplog if the server is shut down in the middle of an applyOps.
We can't use a single WUOW in the general case because applyOps needs to support operations like building an index that are illegal inside of a WUOW. However, it should be possible to detect if all ops are simple single-document CRUD ops and use a single WUOW in that case. This would cover all uses of applyOps that are used when writing to the config servers.
- is related to
-
SERVER-19768 Failed applyOps command does not create an oplog entry even with some successful writes
- Closed
-
SERVER-27246 Running applyOps with an op on a nonexistent database using mmapv1 will crash mongod
- Closed
- related to
-
SERVER-30049 applyOperation_inlock() allows exceptions from Collection::insertDocument() to percolate to caller
- Closed
-
SERVER-21345 applyOps returns wrong error code when document validation fails
- Closed
-
SERVER-29802 Non-atomic applyOps command should not take out a global exclusive lock
- Closed