MongoDB Oplog Difference

Question

Start with a MongoDB replica set with size 5, nodes A through E. A is the active primary and receives writes from the clients with a write guarantee of majority. Say A receives 1, 2, 3, 4. Under my current knowledge, this is a valid state for the replica set's oplogs, since the writes have at least been applied to the majority:

A 1 2 3 4
B 1 4
C 1 2
D 2 3
E 3 4

Now, A is lost.

How do the remaining nodes handle the difference in oplogs, or is there something preventing this situation?

When guaranteeing a write of majority, does that also mean that the majority of the nodes have caught up with the primary's oplog, as in can non-guaranteed writes be delayed until after the guaranteed writes have been processed? In other words, can oplogs ever have a slightly different order, and how does this impact elections?

Answer 1

Non-primary nodes tail the primary's oplog. Meaning each of the non-primary nodes processes the writes in the order that they were applied to the primary. Therefore these are not possible:

B 1 4
D 2 3
E 3 4

The writes are not transfered from primary to non-primary nodes individually based on their write concern.

A write concern W > 1 means that, after the primary has committed the write locally, it waits for W-1 other nodes to acknowledge the write by communicating their oplog position to the primary and having that position move past the write being waited for. If the required number of nodes haven't acknowledged the write in the configured timeout (if any), you get write concern timeout error.

In order for 4 to be acknowledged by any of the nodes, they must have processed writes 1 through 3 previously.