-
Type: Bug
-
Resolution: Done
-
Priority: Blocker - P1
-
Affects Version/s: 2.2.0
-
Component/s: Replication, Storage
-
Fully Compatible
-
ALL
In 2.0.x, oplog entries are applied one at a time on each secondary. Thus, on a restart after a shutdown, only a single op can be applied twice. In 2.2.0, ops are applied in batches, so on a restart, potentially all the ops in the last batch can be reapplied. There are certain sequences of ops that violate idempotency guarantees needed to insure proper replication. In 2.2.0, if we detect such a sequence, the secondary halts replication and shuts down, unable to come back online.
- is duplicated by
-
SERVER-7242 Fatal error when upgrading to Mongo 2.2.0
- Closed
- is related to
-
SERVER-7198 Do not go into rollback before reaching minvalid
- Closed
-
SERVER-7199 Bump minvalid when recloning ops on initial sync
- Closed
- related to
-
SERVER-6671 oplog is not strictly idempotent when unique index is present
- Closed
-
SERVER-3407 oplog is not idempotent for array operators, which could lead to silent data corruption (without journalling)
- Closed
-
SERVER-4781 replica set initial sync failure when update cannot be applied to a future version of an object received via clone
- Closed
-
SERVER-4943 $pop operator may replicate incorrectly
- Closed
-
SERVER-4944 $pull operator may replicate incorrectly
- Closed
-
SERVER-4945 $addToSet operator may replicate incorrectly
- Closed
-
SERVER-5961 $push array size constraint can cause incorrect replication of another field during initial sync
- Closed
-
SERVER-6669 update lacking positional match creates bad document
- Closed
-
SERVER-7177 state transition for replica sets isn't correct
- Closed
-
SERVER-7551 _id Unique key violation during initial sync
- Closed