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.
Operations with oplog IDs 1–950 have occurred at replica boston_hub.
Operations 1–702 have occurred at replica sanfran_hub.
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.
Out-of-date replicas illustrates
this scenario, in which each replica is out of date with respect to the operations
originating at the other replica.
Picturing a replica family as a set of oplog stacks, shown in Out-of-date replicas,
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). Updates between two replicas 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. See c_troubleshoot_ccms_ops.html#sii-trouble-94959.)
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.