Home
Administering
Learn how to administer the product.
Administering HCL VersionVault MultiSite
Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
Troubleshooting MultiSite operations
When you encounter a situation where running an HCL VersionVault MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.
Restoring and replacing VOB replicas
Occasionally, a VOB storage directory is lost. This can occur because of a hardware failure (for example, disk crash), a software failure (for example, operating system-level file system corruption), or a human error (for example, an rm –fr or del command). If an unreplicated VOB storage directory 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.

Administering
Learn how to administer the product.
- Administering HCL VersionVault
  Learn about performing administrative tasks for an HCL VersionVault community including managing software licenses, user and group accounts, VersionVault server and client hosts, shared data, and the network that connects them.
- Administering platforms for HCL VersionVault
  Learn how to perform HCL VersionVault administrative tasks on supported platforms.
- Administering HCL VersionVault MultiSite
  Learn to configure and manage the HCL VersionVault MultiSite environment to support development activities at different locations.
  - Introduction
    HCL VersionVault MultiSite adds a powerful capability to HCL VersionVault. With MultiSite, developers at different locations can use the same HCL VersionVault versioned object base (VOB). For HCL VersionVault, each location (site) has its own copy (replica) of the VOB. 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.
  - MultiSite operation
  - Implementation planning
    Before you install and use HCL VersionVaultHCL Compass MultiSite, you need to plan your implementation.
  - 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.
  - 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.
  - Feature levels
    Feature levels allow different replica hosts in a VOB family to run different versions of HCL VersionVault. You can raise the feature level of either a single replica host or an entire VOB family.
  - Creating VOB replicas
    Before creating a replica, you must make decisions about branching, mastership, identities and permissions preservation, and method of packet delivery.
  - Replica synchronization
    Replica synchronization uses the same export-transport-import procedure that is used during replica creation.
  - Administering replicas
  - Using MultiSite for VOB backup and interoperability
    You can use HCL VersionVault MultiSite to back up a VOB and to provide access to VOBs in a heterogeneous network.
  - Troubleshooting MultiSite operations
    When you encounter a situation where running an HCL VersionVault MultiSite command produces an unexpected result, or produces a warning or error message, the information in this section can assist you in troubleshooting the problem.
    - General MultiSite troubleshooting tips
      Many problems can be clarified, if not solved, by examining the various log files, checking your system configuration, and listing the history of exports.
    - Replica export problems
      Common mkreplica –export problems include specifying a new replica name that matches one that already exists or having an old package left over from a previous failed run.
    - Replica import problems
      Common problems encountered while attempting to import an update packet include permissions issues, naming conflicts in the object or tag registry.
    - Synchronization export problems
      Problems encountered while during the export phase of synchronization typically are the result of not being able to find the appropriate oplog entry.
    - Transport problems
      This section describes problems that can occur during the transport phase of synchronization.
    - Synchronization import problems
      This section describes problems that can occur during the import phase of synchronization.
    - Running epoch_watchdog
      The epoch_watchdog script checks whether a replica’s epoch numbers have rolled back without a restorereplica command being run.
    - Restoring and replacing VOB replicas
      Occasionally, a VOB storage directory is lost. This can occur because of a hardware failure (for example, disk crash), a software failure (for example, operating system-level file system corruption), or a human error (for example, an rm –fr or del command). If an unreplicated VOB storage directory 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.
      - Restoring a replica from backup
        If you lock your primary replica to back it up, you must restore it from the backup medium and perform the restorereplica procedure.
      - Replacing an existing replica
        If you never lock your primary replica and rely solely on a replica at your site as backup, you must replace the replica completely. If you must replace an existing replica, you can re-create it from one of the other replicas in the family.
    - Restoring replica storage that has been accidentally deleted
      This is the process to follow when a replica's storage directory is lost, and there is no backup to be restored.

Restoring and replacing VOB replicas

Occasionally, a VOB storage directory is lost. This can occur because of a hardware failure (for example, disk crash), a software failure (for example, operating system-level file system corruption), or a human error (for example, an rm –fr or del command). If an unreplicated VOB storage directory 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.

Similarly, if you lose the storage directory of a replicated VOB (that is, the storage for the replica used by developers at your site), you can restore a recent copy from backup. But matters are more complicated:

Some of the work done between the time of the backup and the time of the failure may be recoverable. If some of the operations were sent to other replicas in update packets, these operations must be retrieved and imported.
The restored copy of the replica is out of date. You must make this replica consistent with the other replicas in the VOB family before development can proceed in the replica. Failure to reestablish consistency can lead to irreparable damage.

Because this procedure involves substantial effort, it is intended for situations where serious damage has occurred. (For example, the disk containing a replica is unusable.)

The method you use to restore the replica depends on how you back it up:

If you lock your primary replica to back it up, you must restore it from the backup medium and perform the restorereplica procedure. See Restoring a replica from backup.
If you never lock your primary replica and rely solely on a replica at your site as backup, you must replace the replica completely. See Replacing an existing replica.

Have feedback?
Google Analytics is used to store comments and ratings. To provide a comment or rating for a topic, click Accept All Cookies or Allow All in Cookie Preferences in the footer of this page.