Resets epoch row table so changes in lost packets are resent
Product | Command type |
---|---|
MultiSite | multitool subcommand |
Platform |
---|
UNIX |
Windows |
The recoverpacket command resets the epoch row at a sending replica to reflect the last synchronization sent to a receiving replica before a particular time. It scans through a list of epoch rows saved at the time of each export, looking for an entry prior to the time specified. When it finds an entry, it uses the associated row to reset the epoch row for the specified receiving replica. The next time a packet is sent, it includes the changes that were in the lost packet.
When you send an update packet to another replica, success of the transport and import phases is assumed. Therefore, the sending replica's epoch number matrix is updated to reflect that the changes are made at the receiving replica. However, if the packet is lost before reaching the receiving replica, the sending replica's assumption that the receiving replica is up to date is incorrect.
The updated epoch numbers must be returned to the values they had before the packet was sent. Making these corrections to the sending replica's epoch number matrix causes it to include the same changes in the next update packet it sends to the receiving replica.
The administrator at the receiving replica must run an lshistory command to determine the time of the last successful import. The administrator at the sending replica uses this time in the recoverpacket command.
NOTE: If the two sites are not in the same time zone, or you do not send packets at the same time you generate them (for example, you generate packets at midnight and send them at 6:00 A.M.), you must adjust for the time difference.
If there are no saved epoch rows for the replica that are as old as the specified time, the recoverpacket command fails. In this case, the administrator at the receiving site must use the lsepoch command to determine the correct epoch number, and the administrator at the sending site must run chepoch on the sending replica to reset the epoch row. See the chepoch reference page for more information.
Identities: You must have one of the following identities:
VOB owner
root (UNIX)
Member of the ClearCase administrators group (Windows)
Locks: An error occurs if one or more of these objects are locked: VOB.
Mastership: No mastership restrictions.
EVENT RECORDS AND COMMENTS. Default: Creates one or more event records, with commenting controlled by the standard ClearCase user profile (default: -nc). See EVENT RECORDS AND COMMENTS in the multitool reference page. To edit a comment, use cleartool chevent.
SPECIFYING THE TIME. Default: If the time is not specified, recoverpacket uses the current time (and, therefore, resets the epoch row so that the changes in the most recent update packet are resent).
date | := | day-of-week | long-date |
time | := | h[h]:m[m][:s[s]] [UTC [ [ + | - ]h[h][:m[m] ] ] ] |
day-of-week | := | today |yesterday |Sunday | ... |Saturday |Sun | ... |Sat |
long-date | := | d[d]-month[-[yy]yy] |
month | := | January |... |December |Jan |... |Dec |
SPECIFYING THE ROW TO BE MODIFIED. Default: None.
replica-name | Name of the replica (displayed with lsreplica) | |
vob-selector | VOB family of the replica; can be omitted if the current working directory is within the VOB. Specify vob-selector in the form [vob:]pname-in-vob | |
pname-in-vob | Pathname of the VOB-tag (whether or not the VOB is mounted) or of any file-system object within the VOB (if the VOB is mounted) |
Reset the epoch row for replica sanfran_hub so that changes sent since last Monday will be included in the next packet that is sent.
multitool recoverpacket -nc -since Monday sanfran_hub
Reset the epoch row for replica boston_hub so that the changes included in the most recent update packet will be included in the next packet that is sent.
multitool recoverpacket -c "send latest packet" boston_hub@\dev
Determine the last successful import at replica bangalore, reset the epoch row at replica boston_hub, and send an update packet.
cleartool lshistory replica:bangalore@\dev
19-Oct.15:36 smg import sync from replica "boston_hub" to replica
"bangalore"
"Imported synchronization information from replica "boston_hub".
...
At replica boston_hub (remember to adjust for the time zone difference):
multitool recoverpacket -since 19-Oct.05:06 bangalore@/vobs/dev
Using epoch information from Monday 10/19/99 05:05:45
Epoch row for replica "bangalore" successfully reset.
multitool syncreplica -export -fship bangalore@/vobs/dev
Generating synchronization packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_22-Oct-99.15.44.28_48
96_1
- shipping order file is
/usr/atria/shipping/ms_ship/outgoing/sh_o_sync_boston_hub_22-Oct-99.15.44.
28_4896_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet
/usr/atria/shipping/ms_ship/outgoing/sync_boston_hub_22-Oct-99.15.44.28_48
96_1
chepoch, lsepoch, restorereplica
VOB Operations and the Oplog in Chapter 1, Introduction to MultiSite
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |