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):
- 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.)
- 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.
- If boston_hub can export update packets:
- On host minuteman, send update packets to sanfran_hub and bangalore from
boston_hub:
multitool syncreplica –export –fship sanfran_hub bangalore
- On the hosts where sanfran_hub and bangalore physically reside, import the packet
from boston_hub:
multitool syncreplica –import –receive
- On host minuteman, send update packets to sanfran_hub and bangalore from
boston_hub:
- Back up boston_hub’s VOB storage to a storage medium.
- At sanfran_hub, create a new replica, boston_hub2.
multitool mkreplica –export –workdir /tmp/create –nc –fship minuteman:boston_hub2
- If you did not use the –fship option in the preceding step, transport the replica-creation packet to the host minuteman.
- Create the new replica. On host minuteman:
- 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
- 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
- Mount dev2:
cleartool mount /vobs/dev2
- Unregister and remove the VOB tag for boston_hub:
- Make sure that boston_hub2 can synchronize successfully:
- 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.)
- Create and send update packets to sanfran_hub and bangalore:
multitool syncreplica –export –fship sanfran_hub bangalore
- At sanfran_hub and bangalore, import the update packet:
multitool syncreplica –import -receive
- At sanfran_hub and bangalore, list the new type created in Step 8a:
cleartool lstype type-selector
- Transfer mastership of all objects in boston_hub to boston_hub2.
- Determine which replica masters boston_hub.
- 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
- If boston_hub did not master itself, send an update packet from the master replica to boston_hub2 and import it.
- Make sure that sanfran_hub, bangalore, and boston_hub2 can export and import update packets successfully.
- At the replica that masters boston_hub, remove the replica object for boston_hub:
multitool rmreplica boston_hub
- Synchronize all replicas in the family.
- Remove the physical storage for boston_hub with standard operating system commands.
- 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.)