This section describes the mechanism that supports synchronization. This information is not required to use MultiSite, but is helpful when you want to deepen your understanding of the error-recovery facilities described in Troubleshooting MultiSite Operations.
Most changes to a replicated database are recorded as entries in an operation log (oplog). These entries store all the information required to replay the changes in another replica:
The exact kind and amount of information varies with the specific operation. For example, an oplog entry for the submission of a new record has different, and more, information than an oplog entry for modifying an existing record.
Note: You can delete a replica’s oplog entries after they have been used to update other replicas. For more information, see Scrubbing Parameters for Replicas.
The history of an unreplicated database is a linear sequence of operations (Figure 3).
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.
Figure 4 shows the state of two replicas in 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 5 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 Figure 5, 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 6 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.)
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.
An epoch number is the total number of operations that originated at a particular replica. In Figure 4, the epoch number for boston_hub is 950.
The MultiSite synchronization scheme attempts to minimize the amount of data transmitted among replicas. Each replica keeps track of these epoch numbers:
Table 1 shows how these epoch numbers fall into an epoch number matrix. Each replica maintains its own such matrix, revising its rows as work occurs locally and as it exchanges update packets with other replicas:
Note that a syncreplica –export command updates epoch numbers immediately. It does not wait for acknowledgment from the importing replica that the packet has been received and applied correctly. During normal MultiSite processing, no manual intervention is required to maintain the accuracy of the epoch number matrices for the various replicas. However, failure to apply a packet may require manual intervention, as described in Recovering from Lost Packets.
The contents of this matrix are reported by the lsepoch command at the boston_hub replica:
multiutil lsepoch -clan telecomm -site boston_hub -family PRODA -user bostonadmin -password secret Multiutil: Estimates of the epochs from each site replayed at site ’boston_hub’ (@minuteman): boston_hub: 950 sanfran_hub: 504 Multiutil: Estimates of the epochs from each site replayed at site ’sanfran_hub’ (@goldengate): boston_hub: 912 sanfran_hub: 504
A syncreplica –export command entered at boston_hub uses this matrix as follows to generate an update destined for sanfran_hub:
multiutil lsepoch -clan telecomm -site boston_hub -family PRODA -user lexadmin -password secret Multiutil: Estimates of the epochs from each site replayed at site ’boston_hub’ (@minuteman): boston_hub: 950 sanfran_hub: 504 Multiutil: Estimates of the epochs from each site replayed at site ’sanfran_hub’ (@goldengate): boston_hub: 950 sanfran_hub: 504
If a family includes more than two replicas, synchronization can occur indirectly. A replica can include nonlocal changes in update packets. For example, if the boston_hub replica exchanges updates with the sanfran_hub and bangalore replicas, it sends bangalore oplog entries that it has received previously from sanfran_hub. These entries may or may not bring replica bangalore up to date on sanfran_hub’s changes. (An update sent from sanfran_hub to bangalore does bring bangalore up to date.)
Note: If a replica does not receive packets directly from some replicas in its family, its rows for those replicas may contain zeros. This is expected behavior.
Table 2 shows replica boston_hub’s epoch number matrix.
The contents of this matrix are reported by the lsepoch command:
multiutil lsepoch -clan telecomm -site boston_hub -family PRODA -user susan -password passwd Multiutil: Estimates of the epochs from each site replayed at site ’boston_hub’ (@minuteman): boston_hub: 950 sanfran_hub: 504 bangalore: 653 Multiutil: Estimates of the epochs from each site replayed at site ’sanfran_hub’ (@goldengate): boston_hub: 912 sanfran_hub: 504 bangalore: 653 Multiutil: Estimates of the epochs from each site replayed at site ’bangalore’ (@ramohalli): boston_hub: 709 sanfran_hub: 221 bangalore: 653
A syncreplica –export command at the Boston site uses this matrix to export an update for the bangalore replica:
multiutil lsepoch -clan telecomm -site boston_hub -family PRODA -user susan -password passwd Multiutil: Estimates of the epochs from each site replayed at site ’boston_hub’ (@minuteman): boston_hub: 950 sanfran_hub: 504 bangalore: 653 Multiutil: Estimates of the epochs from each site replayed at site ’sanfran_hub’ (@goldengate): boston_hub: 912 sanfran_hub: 504 bangalore: 653 Multiutil: Estimates of the epochs from each site replayed at site ’bangalore’ (@ramohalli): boston_hub: 950 sanfran_hub: 504 bangalore: 653