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.

About this task

For example, if you use MultiSite as your only backup mechanism and you must restore from a backup replica, you have to replace the working replica.

In this procedure, "backup replica" refers to the replica from which you restore the lost or deleted replica. If you have multiple replicas in the family and you use more than one as a backup, use the replica that has most recently imported an update packet from the lost replica.

Attention: Do not use this procedure to fix import failures unless you have tried all other solutions and your support representative advises you to follow these steps.
To replace a replica, use the following procedure (assume the boston_hub replica on host minuteman is to be replaced, and sanfran_hub and bangalore are the other replicas in the family):
  1. For all views that use boston_hub, use the lsprivate command to list view-private and checked-out files. (To list views for which the VOB holds objects, use the cleartool describe vob: command.)
  2. Check in all files (if possible) and save copies of view-private files out of the view. If you plan to save the views, use the procedure in Saving views from the replaced replica at this point.
  3. If boston_hub can export update packets:
    1. On host minuteman, send update packets to sanfran_hub and bangalore from boston_hub:
      multitool syncreplica –export –fship sanfran_hub bangalore
      
    2. On the hosts where sanfran_hub and bangalore physically reside, import the packet from boston_hub:
      multitool syncreplica –import –receive
      
  4. Back up boston_hub’s VOB storage to a storage medium.
  5. At sanfran_hub, create a new replica, boston_hub2.
    multitool mkreplica –export –workdir /tmp/create –nc –fship 
    minuteman:boston_hub2
    
  6. If you did not use the –fship option in the preceding step, transport the replica-creation packet to the host minuteman.
  7. Create the new replica. On host minuteman:
    1. Unregister and remove the VOB tag for boston_hub:
      cleartool umount /vobs/dev
      cleartool unregister –vob /net/minuteman/vobstg/dev.vbs
      cleartool rmtag –vob /vobs/dev
      
    2. Import the packet you created in Step 5 (include any special options you need):
      
      multitool mkreplica –import –workdir /tmp/ms_wkdir –tag /vobs/dev2
      –vob /net/minuteman/vobstg/dev2.vbs –nc –preserve –vrep boston_hub2 
      /var/adm/devops/clearcase/shipping/ms_ship/incoming/sh_o_repl_sanfran
      _hub_18-May-02.15:50:00_1
      
    3. Mount dev2:
      cleartool mount /vobs/dev2
      
  8. Make sure that boston_hub2 can synchronize successfully:
    1. Set a view, change to a directory in /vobs/dev2, and generate a new label or attribute type. (Use a new view, not an old one that may have been used in boston_hub.)
    2. Create and send update packets to sanfran_hub and bangalore:
      multitool syncreplica –export –fship sanfran_hub bangalore
      
    3. At sanfran_hub and bangalore, import the update packet:
      multitool syncreplica –import -receive
      
    4. At sanfran_hub and bangalore, list the new type created in Step 8a:
      cleartool lstype type-selector
      
  9. Transfer mastership of all objects in boston_hub to boston_hub2.
    1. Determine which replica masters boston_hub.
    2. If boston_hub mastered itself, run the following command at boston_hub2; if another replica masters boston_hub, run the following command at that replica:
      multitool chmaster –all –obsolete_replica boston_hub boston_hub2
      
    3. If boston_hub did not master itself, send an update packet from the master replica to boston_hub2 and import it.
  10. Make sure that sanfran_hub, bangalore, and boston_hub2 can export and import update packets successfully.
  11. At the replica that masters boston_hub, remove the replica object for boston_hub:
    
    multitool rmreplica boston_hub
    
  12. Synchronize all replicas in the family.
  13. Remove the physical storage for boston_hub with standard operating system commands.
  14. Remove the views that were used in boston_hub. (If you want to keep these views, use the procedure in Saving views from the replaced replica.)