Reputation: 7092
Suppose we have 3-node replica set (1m,2s,3s). We are going to apply few sequential updated on the same document:
Questions:
Upvotes: 3
Views: 298
Reputation: 13795
Steps 1 and 2 are mutually exclusive. One of them will happen, but not both. This is because MongoDB's oplog is sequential in nature.
To elaborate, let's assume step 1 and step 2 are sequential in time.
After step 1, the oplog contains: Start -> update1
After step 2, the oplog contains: Start -> update1 -> update2
After step 3, whichever node contains the latest data (could be update1
only, or both update1
and update2
, it doesn't matter) will be elected primary.
The next read into the set will return the latest update that managed to get replicated before the primary went offline. Of course, it is entirely possible that neither updates get replicated, giving the next read the Start
state. The point is, the set will never get confused regarding the sequence of updates.
If the new primary contains only update1
(e.g. update2
did not manage to get replicated), then when the old primary comes back online, it will go into the ROLLBACK
state, where it will remove all traces of update2
. Thus, it is possible to lose update2
if the timing is just right.
To avoid rollbacks in most cases, you would need to perform your writes with write concern majority
, so that update2
will be replicated to the majority of voting nodes, minimizing the chance that it will be rolled back.
The scenario you described is similar to a "split brain" scenario, where it's impossible to tell which update is the correct one. MongoDB replica set protocol was especially designed to avoid this situation.
Upvotes: 3