This topic 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 family. When you remove a
replica, the replicas in its family stop tracking epoch numbers for that replica. Removing a replica
does not delete the VOB database it replicates.
Removing a replica requires two synchronization cycles: one to transfer mastership of all of the
replica's objects to another replica, and one to inform all other replicas that the removed replica
is no longer participating in the update process. Because this information can be communicated only
through the synchronization process, you cannot remove a replica at its own site, because doing so
prevents the replica from creating update packets. After a replica is removed from a family, it no
longer participates in synchronization activities. The replica no longer updates its oplog, and you
cannot transfer mastership of any object in that replica.
About this task
In this scenario, the replica tokyo in the
VOB family \tests is being removed.
Procedure
- 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 that there are no checkouts)
- At the site of the decommissioned replica, transfer mastership
of all objects it masters to another replica. If the decommissioned
replica 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 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. If there are problems you cannot fix,
another replica can recover from the error by assuming mastership
of the objects.
- Export and send an update packet from the decommissioned
replica.
The decommissioned replica must send its final changes, including checkins and mastership
changes, to the replica receiving mastership. The decommissioned replica 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
Generating synchronization packet c:\Program Files\HCL\CCM\
VersionVault\var\shipping\ms_ship\outgoing\
sync_tokyo_23-Dec-02.09.33.02_3447_1
- shipping order file is c:\Program Files\HCL\CCM\VersionVault\var\
shipping\ms_ship\outgoing\
sh_o_sync_tokyo_23-Dec-02.09.33.02_3447_1
Attempting to forward/deliver generated packets...
-- Forwarded/delivered packet c:\Program Files\HCL\CCM\VersionVault\
var\shipping\ms_ship\sync_tokyo_23-Dec-02.09.33.02_3447_1
-
Import the update packet at the replica that is (or will become) the master of the
decommissioned replica.
GOLDENGATE% multitool syncreplica -import -receive
Applied sync. packet /opt/hcl/ccm/versionvault/shipping/ms_ship/
incoming/sync_tokyo_23-Dec-02.09.33.02_3447_1 to
VOB /net/goldengate/vobstg/tests.vbs
- (optional) Determine whether other replicas in the family
believe that any objects are still mastered by the replica to be removed.
At the master replica of the replica to be removed, export and send
an update packet to all other replicas in the VOB family, and then
retrieve mastership information from the remote replicas in the family.
Note that this form of the lsmaster command works only if your
current site has IP connectivity to all other sites.
multitool lsmaster -view admin_view -inreplicas -all tokyo@/vobs/tests
No
output from this command means that the mastership information is
up to date for the replica that is to be removed. If
lsmaster returns
output, contact Support and do not attempt to remove the replica.
-
At the master replica, remove the decommissioned replica.
GOLDENGATE% multitool rmreplica tokyo@/vobs/tests
Deleted replica "tokyo".
-
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
Generating synchronization packet ...
-
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".
-
On the server where the rmvob command was executed, restart HCL
VersionVault.