This chapter covers how the pieces of a replica set fit together, including:
How replica set members replicate new data
How bringing up new members works
How elections work
Possible server and network failure scenarios
Replication is concerned with keeping an identical copy of data on multiple servers. The way MongoDB accomplishes this is by keeping a log of operations, or oplog, containing every write that a primary performs. This is a capped collection that lives in the local database on the primary. The secondaries query this collection for operations to replicate.
Each secondary maintains its own oplog, recording each operation it replicates from the primary. This allows any member to be used as a sync source for any other member, as shown in Figure 10-1. Secondaries fetch operations from the member they are syncing from, apply the operations to their data set, and then write the operations to the oplog. If applying an operation fails (which should only happen if the underlying data has been corrupted or in some way differs from the primary), the secondary will exit.
Figure 10-1. Oplog keep an ordered list of write operations that have occurred. Each member has its own copy of the oplog, which should be identical to the primary’s (modulo some lag).
If a secondary goes down for any reason, when it restarts it will start syncing from the last ...