Import phase

The import phase of the replica creation process occurs at the new replica's site. It consists of verifying the packet's arrival using the lspacket command, creating the replica using the import form of the mkreplica command, deleting the replica creation packet if necessary, and setting the replica properties such as identities and permissions, self-mastership, and feature level.

Before you begin

Note: Before you can start the import phase of VOB replica creation, you must have completed the steps specified under Export phase (and under some circumstances, the Transport phase as well).

About this task

These steps take place at the new replica’s site.

Procedure

  1. Verify the packet’s arrival by running lspacket on the receiving host.
    By default, lspacket searches all the MultiSite storage bays for packets. For example, if host goldengate is the receiving host:
    
GOLDENGATE% multitool lspacket
Packet is: /opt/hcl/ccm/versionvault/shipping/ms_ship/
incoming/repl_boston_hub_1
6-Aug-03.09.49.36_14075_1
Packet type: Replica Creation
VOB family identifier is: 12a3456b.78c901d2.e3ab.45:67:89:c0:1d:e2
Comment supplied at packet creation is:
Packet intended for the following targets:
sanfran_hub
The packet sequence number is 1
  2. Enter the import form of the replica-creation command.
    Notes on the import phase of replica creation:
    • This replica is permissions-preserving, so the user who executes this command becomes the owner of the new VOB replica and all elements in it. This user’s primary group is the group for all elements. Typically, administration is easier if this user is not the root user or a member of the HCL VersionVault administrators group.
    • As described under Prerequisites for creating a new VOB replica, the work directory must have at least 1.62 GB of free space.
    • You can bypass the Should I create this replica? prompt during replica creation by specifying the –vreplica option with the new replica’s name. This example does not specify that option.
    • If you create a permissions-preserving replica, you can bypass the prompt during replica creation by specifying the –nprompt option with the –perms_preserve option. This example does not specify that option.
    • You must specify the pathname of the incoming packet as listed by the lspacket command. 
    GOLDENGATE% multitool mkreplica –import –perms_preserve –work /tmp/wk
–tag /vobs/dev –public –password 1234xyz –vob /vobstg/dev.vbs
/opt/hcl/ccm/versionvault/shipping/ms_ship/incoming/
repl_boston_hub_16-Aug-00.09.49.36_14075_1
multitool: Warning: In a permissions-preserving replica, cleartool
protect operations will fail on client machines running VersionVault
versions associated with feature level 3 or lower.
Should I create a permissions-preserving replica? [no] yes
The packet can only be used to create replica "sanfran_hub"
- VOB family is 87f6265b.72d911d4.a5cd.00:01:80:c0:4b:e7
- replica OID is 0eaa6fc3.737d11d4.adbe.00:01:80:c0:4b:e7
Should I create this replica? [no] yes
Comments for "sanfran_hub":
replica of /vobs/dev from Boston
.

Processing packet /opt/hcl/ccm/versionvault/shipping/ms_ship/
incoming/repl_boston_hub_1
6-Aug-03.09.49.36_14075_1...
Loading database...
Dumped schema version is 54
55 events loaded.
77 pass 2 actions performed.
Loader done.
Registering VOB mount tag "/vobs/dev"...
VOB replica successfully created.
Host-local path: goldengate:/vobstg/dev.vbs
Global path:     /net/goldengate/vobstg/dev.vbs
VOB ownership:
owner purpledoc.com/jcole
group purpledoc.com/user
  3. Delete the replica-creation packet.
    Update packets are deleted automatically.
  4. If the new replica preserves identities and permissions, ensure that the owner, group, and group list of the new VOB are the same as the owner, group, and group list of the other identities- and permissions-preserving replicas in the VOB family.

    To change these values, run the cleartool protectvob command on the new VOB replica.

  5. If the new replica preserves identities and permissions or permissions only, send an update packet to all other replicas in the VOB family.
    If you create a preserving replica, inform other replicas in the VOB family of this property. For example, sanfran_hub preserves permissions, so the San Francisco administrator enters this command:
    GOLDENGATE% multitool syncreplica –export –c "permissions-preserving"
–fship boston_hub
...
  6. Make the new replica self-mastering.

    For details about this procedure, see Transferring mastership of a replica object.

    Note: You must complete this step before you can set the new replica’s feature level.
  7. Set the feature level of the new replica to the feature level of the version of HCL VersionVault running on the replica host.

    To determine the feature level of the version of HCL VersionVault, enter the cleartool –ver command on the replica host to display the HCL VersionVault version. Then consult the VersionVault and VersionVault MultiSite Release Notes for the feature level associated with the version.

    To set the new replica’s feature level, enter a chflevel command on the replica host: 
    cleartool chflevel –replica 
feature-level replica-selector
    For example: 
    cleartool chflevel –replica 5 sanfran_hub@/vobs/dev
Replica feature level raised to 5.
  8. Send an update packet to all other replicas in the VOB family, to inform them of the new replica’s feature level.
    For example: 
    GOLDENGATE% multitool syncreplica –export –c "new feature level" 
–fship boston_hub
...
    Note: You may want to consider raising the VOB family feature level. For more information, see Feature levels .
  9. Create a branch type for work in the new replica.
    In our example, the San Francisco developers use branches of type sanfran_main.
    GOLDENGATE% cleartool mkbrtype sanfran_main
Comments for "sanfran_main":
sanfran branch for work on dev project
.

Created branch type "sanfran_main".
    Subbranches named sanfran_main are created as necessary. The following config spec automates the creation of the sanfran_main branches:
    element * CHECKEDOUT
element * .../sanfran_main/LATEST
element * SANFRAN_BASE –mkbranch sanfran_main
element * V1.0 –mkbranch sanfran_main
element * /main/0 –mkbranch sanfran_main

    This config spec is defined in terms of a branch type (sanfran_main), which is mastered by replica sanfran_hub, and label types (SANFRAN_BASE and V1.0), which are mastered by replica boston_hub. The San Francisco developers cannot create instances of the SANFRAN_BASE label type or move any existing SANFRAN_BASE labels, but there is no reason for them to do so.

  10. Verify the mastership of the new branch type.
    GOLDENGATE% 
cleartool describe brtype:sanfran_main@/vobs/dev
branch type "sanfran_main"
  created 16-Aug-03.18:12:23 by John Cole (jcole.user@goldengate)
  "sanfran branch for work on dev project"
  master replica: sanfran_hub@/vobs/dev
...
  11. (For IP-connected replicas) At each site, mark any sibling replicas that have IP connectivity to the current replica.

    For more information, see Setting the connectivity property for a VOB replica.

    At the boston_hub replica:
    multitool chreplica –isconnected sanfran_hub@/vobs/dev
Updated replica information for "sanfran_hub".
    At the sanfran_hub replica:
    multitool chreplica –isconnected boston_hub@/vobs/dev
Updated replica information for "boston_hub".
  12. Begin development.

    Developers in San Francisco can access the new replica in the same way they access an unreplicated VOB.