Operation tracking for each replica

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 VOB or database is a linear sequence of operations (History of changes to a database ).
Figure 1: History of changes to a database


State of a family 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.

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.
Figure 3: Out-of-date replicas


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.)
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.