Synchronization Import Problems


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

Packets Accumulate in Incoming Storage Bay

A recoverable error occurs when an update packet is lost and is not applied to your replica. These are the symptoms:

To verify that a packet is missing and determine which operations are needed:

  1. Enter a syncreplica –import –receive command, which processes all incoming packets in the storage bay in the correct order. If syncreplica fails to process any of them, a packet is missing.
  2. Enter a syncreplica –import command that specifies the oldest packet in the storage bay:
  3. multiutil syncreplica -import -clan telecomm -site sanfran_hub -family DEV 
    -user jcole -p passwd packet-pathname
    Multiutil: Packet packet-pathname not processed...
    Multiutil: The UPDATE_PACKET packet sent from BOSTON_HUB at 
    2002-03-25 17:42:41  for ‘DEV’ cannot be replayed: This replica has 
    not replayed epoch 6 from replica BOSTON_HUB, it has only replayed 
    through 2.
    Multiutil: The UPDATE_PACKET packet sent from BOSTON_HUB at 
    2002-03-25 17:42:41  for ‘MASTR’ cannot be replayed: This replica 
    has not replayed epoch 8 from replica BOSTON_HUB, it has only 
    replayed through 6.

In this example, one or more update packets are missing, containing operations 3-6 originally occurring in the user database in the DEV family at the boston_hub site and operations 7-8 in the schema repository at the boston_hub site. In general, a packet can contain operations from several replicas; the syncreplica –import command fails if operations are missing from any replica.

Locate the missing packets. They may be on media that you forgot to process or in packet files that were not processed because your store-and-forward configuration (the shipping.conf file on UNIX; the MultiSite Control Panel on Windows) specifies the wrong storage bay. If you locate the missing packets, do one of the following things:

If you cannot locate the missing packets, see Recovering from Lost Packets.

Packet Is Not Applicable to Any Local Replicas

Import can fail with the following message:

multiutil: Error: Sync. packet pathname is not applicable to any local 
replicas.

This error can occur when a synchronization server has been moved and the host-name property has not been updated with the chreplica command.

To verify that the host-name property is wrong, use the lsreplica command. For example, if the above error occurred at the bangalore replica:

multiutil lsreplica -site bangalore -user kumar -p secret -long bangalore
Name:bangalore; Clan:TELECOMM; Family:PRODA; Host:shiphost1; Status: 
NORMAL, NOT CONNECTED; Description:Production database

If the host name is incorrect, use the chreplica command to change it. Then, send an update packet to the other replicas in the family.

Read from Input Stream Fails

If a syncreplica –import command fails with a message like this one, the packet is corrupted:

Error: Read from input stream failed: No such file or directory

Delete the packet and ask the administrator at the sending replica to re-create the packet and send it again (see Recovering from Lost Packets). Then import it.

Miscellaneous Problems

Processing of an incoming replica-creation or update packet may fail because of these conditions:

Make sure that multiple syncreplica –import commands do not run in the same replica simultaneously. In such cases, fix the problem and reenter the syncreplica –import command.

Recovering from Lost Packets

There are several circumstances in which an update packet is generated but is never applied at one or more of its destinations:

The syncreplica –export command assumes successful delivery of the update packet it generates. For example, when replica boston_hub sends an update to replica sanfran_hub, the syncreplica command assumes that the operations originating at boston_hub are imported to the sanfran_hub replica. For simplicity, this example does not reflect the fact that the update packet can also contain operations that originated at other replicas in the family.

If the packet is lost, boston_hub must reset its estimate of the state of replica sanfran_hub. After this correction is made, the next update packet sent from boston_hub to sanfran_hub contains the operations sanfran_hub needs.

To reset the epoch row, use the method described here.

  1. At the receiving replica, sanfran_hub, display the replica’s epoch number matrix:
  2. multiutil lsepoch -clan telecomm -site sanfran_hub -family PRODA -user jcole -p secret sanfran_hub
    Multiutil: Estimates of the epochs from each site replayed at site ’sanfran_hub’ (@goldengate):
    BANGALORE: 950
    BOSTON_HUB: 1300
    SANFRAN_HUB: 2000

  3. Use this output in a chepoch command at the sending replica, boston_hub. This sets the boston_hub epoch number estimates for sanfran_hub to the actual values of the sanfran_hub epoch number matrix:
  4. multiutil chepoch -clan telecomm -site boston_hub -family PRODA -user 
    bostonadmin -password secret sanfran_hub bangalore=950 boston_hub=1300 
    sanfran_hub=2000 
    Multiutil: Change the estimate for the epochs of site ‘bangalore’ 
    replayed at site ‘sanfran_hub’ to 950 [yes|NO|quit]yes
    
    Multiutil: Change the estimate for the epochs of site ‘boston_hub’ 
    replayed at site ‘sanfran_hub’ to 1300 [yes|NO|quit]yes
    
    Multiutil: Change the estimate for the epochs of site ‘sanfran_hub’ 
    replayed at site ‘sanfran_hub’ to 2000 [yes|NO|quit]yes
    
    Multiutil: 3 epoch estimate(s) for site ‘sanfran_hub’ successfully 
    changed; 0 failures.
    
    Multiutil: Estimates of the epochs from each site replayed at site 
    ‘sanfran_hub’ (@goldengate):
    BANGALORE: 950
    BOSTON_HUB: 1300
    SANFRAN_HUB: 2000