This section describes how to remove a replica. You must complete all steps; if you do not, synchronization and mastership problems can occur in other replicas in the VOB family.
NOTE: If a VOB replica is deleted mistakenly and you want to restore it from backup, see Restoring and Replacing Replicas. If a VOB replica's storage directory is lost and there is no backup, see Cleaning Up from Accidental Deletion of a Replica.
In this scenario, the replica tokyo in the VOB family \tests is being removed.
At the site of the replica to be removed, complete all development work in the replica and use lscheckout or the Find Checkouts tool (Windows) to verify that all checkouts are resolved in the replica to be removed:
SHINJUKU> cleartool lscheckout -all \tests
(no output means no checkouts)
Transfer mastership of all objects to another replica.
At the site of the replica to be removed, transfer mastership of all objects mastered by the replica to another replica. If the replica to be removed is not self-mastering, transfer mastership to its master replica. If the replica is self-mastering, you can choose any replica.
In this example, the administrator determines which replica masters tokyo, and then transfers mastership to the master replica (in this example, sanfran_hub):
SHINJUKU> cleartool describe -fmt "%[master]p\n" replica:tokyo@\tests
sanfran_hub@\tests
SHINJUKU> multitool chmaster -all -long sanfran_hub@\tests
Changed mastership of versioned object base \tests
...
Changed mastership of all objects
The replica that receives the mastership can later transfer mastership to other replicas.
If mastership is not transferred for all objects, you must fix the problem and reenter the chmaster -all -long command. For an example, see Transferring Mastership of All Objects Mastered by a Replica. If there are problems you cannot fix, another replica can recover from the error by assuming mastership of the objects. For a description of this procedure, see Cleaning Up from Accidental Deletion of a Replica.
Export and send an update packet from the replica to be removed.
The replica to be removed must send its final changes, including checkins and mastership changes, to the replica receiving mastership. The replica to be removed can broadcast its final changes to all other replicas, but it must update its master replica (sanfran_hub in this example).
SHINJUKU> multitool syncreplica -export -fship sanfran_hub@\tests
Import the update packet at the replica that is (or will become) the master of the replica to be removed.
GOLDENGATE% multitool syncreplica -import -receive
At the master replica, remove the replica.
GOLDENGATE% multitool rmreplica tokyo@/vobs/tests
At the master replica, export and send an update packet to the remaining replicas in the VOB family.
This update packet notifies the other replicas of the replica removal.
GOLDENGATE% multitool syncreplica -export -fship <replica names>
At the removed replica, remove the VOB storage directory of the removed replica.
SHINJUKU> cleartool rmvob \\shinjuku\vobs\tests.vbs
Remove versioned object base "\\shinjuku\vobs\tests.vbs"? [no] yes
Removed versioned object base "\\shinjuku\vobs\tests.vbs".
If you decommission and remove all replicas, the one remaining VOB replica is a regular VOB, and developers no longer need a MultiSite license to access it.
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |