This section describes problems that can occur during the export phase of synchronization.
syncreplica –export can fail with the following warning message:
Can not find oplog from replica replica-name with id oplog-ID Gap in oplog entries may indicate missing oplog entries
(For more information about oplog entries, see The Operation Log and Scrubbing Parameters for Replicas.)
This error occurs when the sending replica’s epoch number matrix does not match its set of oplog entries. For example:
This discrepancy may be an expected condition. For example, when you change the synchronization pattern for a family, replicas that have not communicated with each other in the past start exchanging update packets. Synchronizing two replicas (syncreplica –export followed by syncreplica –import) updates epoch number matrix rows for the sending and receiving replicas, but it does not revise the row for any other replica. If two replicas rarely (or never) send updates to each other directly, the relevant rows in their epoch number matrices are out of date (possibly consisting of all zeros). This is not a problem, as long as the replicas receive operations indirectly, for example, through a hub replica.
In this case, you must inform sydney about the true state of buenosaires, information that is not reflected in sydney’s epoch number matrix. This information enables sydney to determine which oplog entries must be sent to buenosaires.
If the sites have an IP connection, use the procedure in chepoch –actual Method. Otherwise, use the procedure in lsepoch and chepoch Method.
At sydney, use the chepoch –actual command to contact buenosaires, retrieve its actual state, and reset the epoch row for buenosaires.
Proceed as follows:
multitool lsepoch buenosaires@/vobs/tests For VOB replica "/vobs/tests": Oplog IDs for row "buenosaires" (@ mardelplata): oid:ac93e6cf.14a311d5.bbcc.00:01:80:c0:4b:e7=4000 (buenosaires) oid:c6b8c9b0.038d11d1.b083.00:60:97:98:42:69=5927 (sydney)
cd /vobs/dev multitool chepoch buenosaires Enter specifications for epochs to change in row "buenosaires" (one per line) oid:ac93e6cf.14a311d5.bbcc.00:01:80:c0:4b:e7=4000 oid:c6b8c9b0.038d11d1.b083.00:60:97:98:42:69=5927 . Change oplog IDs in row "buenosaires" [no] yes Epoch row successfully set.
Note: Have all administrators review their oplog scrubbing procedures. See Scrubbing Parameters for Replicas.
syncreplica –export can fail with the following warning message:
This error message can indicate a serious error, involving an unrecoverable data loss. If the procedures described in Cannot Find Oplog Entry do not work, contact Rational Customer Support.
An export operation can fail with a message like the following:
multitool: Error: Type manager "z_text_file_delta" failed construct_version operation. multitool: Error: Could not get statistics of the version data file for this operation. multitool: Error: Synchronization update terminated prematurely due to error -- aborting.
This situation can occur when an export operation tries to access an element that is being modified by a user. In this case, retry the export.
Problems with packet delivery are recoverable errors. In many cases, the MultiSite automatic-retry capability recovers from errors.
A replica-creation or update packet submitted to the store-and-forward facility for transport to one or more other hosts is accompanied by a shipping order file. (A logical packet can include multiple physical packets, each with its own shipping order.) The shipping order typically has an expiration time, determined by one of the following:
Any number of delivery attempts may take place before the shipping order expires.
You can receive the following message during export if you specify the sending replica as a destination:
If the sending replica is the only replica you specified, the syncreplica –export command fails. If you specified other replicas, this message is printed as a warning, and the syncreplica –export command continues its processing.