Synchronization Export Problems


This section describes problems that can occur during the export phase of synchronization.

Cannot Find Oplog Entry

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.

chepoch –actual Method

At sydney, use the chepoch –actual command to contact buenosaires, retrieve its actual state, and reset the epoch row for buenosaires.

multitool chepoch –actual replica:buenosaires@/vobs/tests 

lsepoch and chepoch Method

Proceed as follows:

  1. At buenosaires (destination replica), run lsepoch to determine the actual state of buenosaires:
  2. 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)
  3. Send the lsepoch command output back to the sending site, where the administrator of sydney uses this data in a chepoch command to inform sydney about the actual state of buenosaires.
  4. 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.
  5. At sydney, enter the original syncreplica –export command.
    • If the command fails, buenosaires is in jeopardy. Have other replicas in the family perform Step 1 through Step 3, taking the role of sydney to exchange update packets with buenosaires. The hope is that some other replica has not yet scrubbed its copies of the missing oplog entries. If no other replica has the missing oplog entries, you must create a new replica. See Replacing an Existing Replica.
    • If the command succeeds and the packet is imported successfully at buenosaires, buenosaires is up to date.

Note: Have all administrators review their oplog scrubbing procedures. See Scrubbing Parameters for Replicas.

Oplog Gap Detected During Creation of Update Packet

syncreplica –export can fail with the following warning message:

Gap in oplog detected for replica replica-name.
Wanted oplog id: oplog-ID.  Got oplog id: oplog-ID.

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.

Export Failure During Version Construction

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.

Packets Accumulate in Outgoing Storage Bay

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.

Replica Cannot Update Itself

You can receive the following message during export if you specify the sending replica as a destination:

A replica cannot update itself

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.