|
|
This section describes the VOB database mechanism that supports replica 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 Chapter 10, Troubleshooting MultiSite Operations.
Most changes made to a VOB are recorded as event records in the VOB database. Each event record describes a change. For a replicated VOB, operation log entries (oplogs) are created also. These entries store all the information required to replay the changes in another replica:
The identity of the replica where the change originally took place.
The change to the VOB database; for example, creation of a new element, checkin of a new version, attaching of an attribute, and so on.
The change to the storage pool, if any; for example, the contents of a new version.
NOTE: Version information is not stored in the oplog. When version information is required by syncreplica, it is retrieved from the pools.
The event record generated for the change.
An integer sequence number: 1 for the first change originating at a particular replica, 2 for the next change, and so on. This is called the epoch number or oplog-ID of the oplog entry.
The exact kind and amount of information varies with the specific operation. For example, an oplog entry for the removal of a label has different, and less, information than an oplog entry for a checkout command.
NOTE: Oplog entries are created only for replicated VOBs. You can scrub a replica's oplog entries after they have been used to update other replicas. For more information, see Scrubbing Parameters for VOB Replicas.
The history of an unreplicated VOB is a linear sequence of operations (Figure 4).
Figure 4 History of Changes to an Unreplicated VOB
For a replicated VOB, changes are tracked separately for each replica. (That is why an oplog entry includes the identity of the replica where the operation originated.) Thus, the history of a replicated VOB can be viewed as several stacks of oplog entries. Each stack is represented by a linear sequence of epoch numbers for the operations originating in that replica.
Figure 5 shows the state of two replicas in a VOB family:
Operations with epoch numbers 1-950 have occurred at replica boston_hub.
Operations 1-702 have occurred at replica sanfran_hub.
Figure 5 State of a VOB 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 no current data about the boston_hub replica's state.
Figure 6 illustrates this scenario, in which each replica is out of date with respect to the operations originating at the other replica.
Figure 6 State of a Replicated VOB
Picturing a replicated VOB as a set of oplog stacks, shown in Figure 6, 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 7 shows the two increments. Because sanfran_hub knows its own state, it needs updates only for other replicas. (In certain error-recovery situations, you must reset a replica's data about its own operations. See Chapter 10, Troubleshooting MultiSite Operations.)
Figure 7 Updates Between Two Replicas
NOTE: By the time the packet is imported at sanfran_hub, additional VOB-level changes may have been made at boston_hub. These changes are not included in the update packet.
The MultiSite synchronization scheme attempts to minimize the amount of data transmitted among sites. Each replica keeps track of these epoch numbers:
Changes made in the current replica. The epoch number that indicates how many operations originated at the current replica.
Changes at sibling replicas. When syncreplica writes an operation from an update packet to the current replica, it increments the epoch number for the sibling replica at which the operation originally occurred. This epoch number is the number of operations originating at the sibling replica that have been imported at the current replica.
Current knowledge of the states of other replicas. For each other replica, an estimate of its own changes and other replicas' changes.
Figure 8 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:
When work occurs in the boston_hub replica, its own number of oplog IDs is incremented.
When the boston_hub replica generates an update packet to be sent to sanfran_hub, it revises the sanfran_hub row in its epoch number matrix.
Note that a syncreplica -export command updates epoch numbers immediately. It does not wait for acknowledgment from the receiving site that the packet has been received and applied correctly. During normal ClearCase and 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 Lost Update Packet.
When the boston_hub replica receives an update from sanfran_hub, it revises its own row (boston_hub) and the sanfran_hub row in its epoch number matrix.
Figure 8 Two-Row Epoch Number Matrix at Replica boston_hub
The contents of this matrix are reported by the multitool lsepoch command at the boston_hub replica:
multitool lsepoch
A syncreplica -export command entered at boston_hub uses this matrix as follows to generate an update destined for sanfran_hub:
At boston_hub, the number of local operations is 950 (number in upper-left corner of matrix), and the estimate is that sanfran_hub has been updated only to epoch number 912 (number in lower-left corner).
The update packet that boston_hub sends to sanfran_hub includes boston_hub oplog entries 913-950. After the Boston administrator invokes syncreplica -export, the sanfran_hub row is updated:
multitool lsepoch
If there are more than two replicas in a VOB family, synchronization can occur indirectly. A replica can include nonlocal changes in update packets. For example, if boston_hub exchanges updates with replicas sanfran_hub and bangalore, 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 the VOB family, its rows for those replicas may contain zeros. This is expected behavior.
Figure 9 shows replica boston_hub's epoch number matrix.
Figure 9 Epoch Number Matrix at Replica boston_hub
The contents of this matrix are reported by the lsepoch command:
multitool lsepoch
A syncreplica -export command at Boston uses this matrix to export an update for bangalore:
At Boston, there are 950 local operations (number in upper-left corner of matrix), and the estimate is that bangalore has been updated only to epoch number 709 (lower-left corner).
For operations that originated at sanfran_hub, boston_hub has been updated to epoch number 504, and estimates that bangalore has been updated only to epoch number 221.
The update packet that boston_hub sends to bangalore includes boston_hub oplogs 710-950 and sanfran_hub oplogs 222-504. The output of a multitool lsepoch command at Boston now looks like this:
multitool lsepoch
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
