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 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. See Troubleshooting MultiSite 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.
