Within a replica family, changes are tracked for each replica.
This is why an oplog entry includes the identity of the replica where the
operation originated. Thus, the history of a replica family can be viewed
as several stacks of oplog entries. Each stack is represented by a linear
sequence of oplog IDs for the operations that originate in that replica.
The history of an unreplicated
database is a linear sequence of operations (
Figure 1).
Figure 1. History of changes
to a database
Figure 2 shows the
state of two replicas in a family:
- Operations with oplog IDs 1–950 have occurred at replica boston_hub.
- Operations 1–702 have occurred at replica sanfran_hub.
Figure 2. State of a family
A replica has accurate data only about its own operations. Until it receives
update packets, its information about other replicas is out of date. For example,
replica boston_hub records 950 local operations, but has received update
packets for only 504 sanfran_hub operations. Similarly, replica sanfran_hub records
702 local operations, but has received update packets for only 791 boston_hub operations.
Figure 3 illustrates
this scenario, in which each replica is out of date with respect to the operations
originating at the other replica.
Figure 3. Out-of-date replicas
Picturing a replica family as a set of oplog stacks, shown in
Figure 3,
makes it easy to understand the synchronization process. For example, an update
packet sent from replica
boston_hub to replica
sanfran_hub consists
of increments to the stack for replica
boston_hub (operations 792–950).
Figure 4 shows the two increments.
Because
sanfran_hub knows its own state, it needs updates only for
operations originating at other replicas. (In certain error-recovery situations,
you must reset a replica’s data about its own operations. )
Figure 4. Updates between two replicas
Note: By the time the packet is imported at sanfran_hub, additional
changes may have been made at boston_hub. Those changes are not included
in the update packet.