Home
Administering
Learn how to administer the product.
Administering HCL Compass Multisite
Administering HCL Compass Multisite
Troubleshoot MultiSite operations
There are common situations in which running a HCL Compass MultiSite command produces an unexpected result, sometimes accompanied by a warning or error message.
Synchronization export problems
There are common problems that can occur during the export phase of synchronization.
Cannot find oplog entry
The syncreplica –export command can fail when the sending replica’s epoch number matrix does not match its set of oplog entries.

Administering
Learn how to administer the product.
- Administering HCL Compass
  Learn how to administer the HCL Compass.
- Administering HCL Compass Web
  This section discusses how to administer HCL Compass Web.
- Administering HCL Compass Multisite
  Administering HCL Compass Multisite
  - Introduction
    HCL VersionVault MultiSiteHCL Compass MultiSite adds a powerful capability to HCL VersionVaultHCL Compass. With MultiSite, developers at different locations can use the same HCL VersionVault versioned object base (VOB) HCL Compass database set (a schema repository and its associated user databases). For HCL VersionVault, each location (site) has its own copy (replica) of the VOB. For HCL Compass, each location has its own copies, or replicas, of the schema repository and user databases. At any time, changes made in one replica can be sent in update packets to other replicas. You can manage replicas by using the command-line tools.
  - Implementation planning
    Before you install and use HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
  - Packet transportation methods and configuration
    The method you choose for transporting packets between replicas depends on connectivity. If your replicas do not have IP connectivity, you must use a file-based transport method. If your replicas have connectivity, you can use the store-and-forward facility.
  - Database replica creation
    Creating your database replicas requires careful planning and consideration part of which involves making decisions about mastership and methods of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Database replicas administration
    Sustaining a smoothly functioning MultiSite environment requires dedicated administration. Many administrative processes can drastically change your environment and require careful consideration and planning.
  - Mastership management
    The management of mastership affects how database objects are accessed and manipulated by users in your MultiSite environment. Mastership management is an ongoing process as new objects are entered into the database and users' requirements change.
  - Troubleshoot MultiSite operations
    There are common situations in which running a HCL Compass MultiSite command produces an unexpected result, sometimes accompanied by a warning or error message.
    - Replica export problems
      There are common replica export problems that may occur.
    - Transport problems
      There are problems that can occur during the transport phase of synchronization.
    - Replica import problems
      There are common replica import problems that can occur.
    - Synchronization export problems
      There are common problems that can occur during the export phase of synchronization.
      - Cannot find oplog entry
        The syncreplica –export command can fail when the sending replica’s epoch number matrix does not match its set of oplog entries.
      - Packets accumulate in outgoing storage bay
        A recoverable error can occur when the Shipping Server is unable to contact the receiving host.
      - Replica cannot update itself
        If you specify the sending replica as the destination replica, the syncreplica –export command fails.
    - Synchronization import problems
      The topics in this section describe problems that can occur during the import phase of synchronization.
    - Removing circular duplicate links
      In a replicated HCL Compass environment it is possible to create a circular duplicate link when a defect and its duplicate are both set to the Duplicate state.
    - Naming conflict resolution
      If you do not impose a site-specific naming convention for Workspace items (queries, reports, charts, and so on), users and groups, and other stateless records, it is possible to have different objects with the same name.
    - Lost database replica recovery
      Occasionally, a replica is lost. This loss is usually due to a hardware failure (for example, disk crash), a software failure (for example, OS-level file system corruption), or a human error. If an unreplicated database is lost, you can restore a recent copy from backup and resume development work. The changes made between the time of the backup and the time of the failure are not recoverable.
    - replica repair with multiutil repair
      You can use the multiutil repair command to troubleshoot and repair problems in a replica that might cause some MultiSite commands to fail.
    - Error messages
      The messages listed in this topic are generated by the mkorder, mkreplica, shipping_server, and syncreplica commands.
  - MultiSite command set
    This section summarizes the commands for HCL VersionVault MultiSite and HCL VersionVault that display HCL VersionVault MultiSite information. There are a series of MultiSite commands and API functions that display or modify MultiSite information.

Cannot find oplog entry

The syncreplica –export command can fail when the sending replica’s epoch number matrix does not match its set of oplog entries.

The syncreplica –export command can fail with the following warning message:

Multiutil: Error: 'family' database has exported oplog entries originating 
from replica 'site' through oplog-ID oplog-ID. The next oplog-ID 
to be exported is oplog-ID; it should be oplog-ID. A gap in oplog 
entries may indicate missing oplog entries.

This error occurs when the sending replica’s epoch number matrix does not match its set of oplog entries. For example:

Before sending an update from sydney to buenosaires, syncreplica checks the epoch number matrix for sydney. It determines that the last sydney operation sent to buenosaires was 3620.
Oplog scrubbing in the sydney database has removed some of the operations that follow 3620. The earliest sydney operation remaining in the oplog is 5755.

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 using the chepoch command; this is information that sydney has not received through the standard synchronization mechanism. This information enables sydney to determine which oplog entries to send to buenosaires.

This situation may also occur if you remove oplog entries with the scruboplog command before they are sent to other replicas. You must make sure that you have synchronized the replicas in a family before you scrub oplogs at any of the replicas.