Description
The
startrcrelationship command starts a stand-alone relationship. The command
fails if it is used to start a relationship that is part of a consistency group.
Note: You cannot start a relationship if the primary
and secondary volumes are different sizes.
This command can be specified only to a
relationship that is connected. For a relationship that is idling, this command assigns a copy
direction (primary and secondary roles) and begins the copy process. Otherwise, this command
restarts a previous copy process that was stopped either by a stop command or by some I/O
error.
Note: A command in idling state is rejected if any of the
indicated secondary volumes is the target of an existing FlashCopy map.
If the FlashCopy mapping is active, the
remote copy cannot be started.
If an existing remote copy relationship is stopped by
specifying
stoprcrelationship -access but is restarted and the resultant
secondary volume (depending on the choice of primary) is mapped to a host of type
hide_secondary, that volume is not presented to the host. This is true even
though it is mapped for configuration purposes. The mapped volumes are presented to the host if
the:
- Host type is changed to a type other than hide_secondary
- Remote copy relationship is stopped by specifying stoprcrelationship
-access
- Volume ceases to be a secondary volume because the remote copy relationship is being
deleted or switched
In the idling state, you must provide the -primary parameter.
In other connected states, you can provide the -primary parameter, but it
must match the existing setting.
The
-force parameter is required if consistency would be lost by starting
a copy operation. This situation can occur if input transactions occur on either the primary or
secondary volumes since the
ConsistentStopped or
Idling state occurred. This situation occurs when the relationship
is in either of these states:
- ConsistentStopped but not synchronized
- Idling but not synchronized
After restarting a relationship in either of these states, the data on the secondary
volume is not usable for disaster recovery until the relationship becomes consistent.
A
Global Mirror relationship with a cycling_mode of multi in
either of these states does not require the -force parameter because a
consistent secondary image is retained. However, if such a relationship is in idling state and
written data is received at the secondary volume, the -force flag is
required because the secondary volume has a divergent image that cannot represent a consistent
earlier state.
The
-force parameter is not required if the
relationship is in one of the following states:
- InconsistentStopped
- InconsistentCopying
- ConsistentSynchronized
However, the command does not fail if you specify the
-force
parameter.
You do not have to specify the -force parameter for
relationships with configured secondary change volumes. If you specify
startrcrelationship for an idling relationship, consistency
protection is disabled if the secondary volume is written to. This means that you must specify
the -force parameter.
A Global Mirror relationship with a cycling
mode of:
- none uses the non-cycling Global Mirror algorithm
- multi must:
- Use a change volume that is configured at the primary volume (or the command fails)
- Use a change volume that is configured at the secondary volume (or the command
fails)
- Perform multiple cycles of cycling
After you create a background copy the relationship remains in copying state, wait
for the remainder of the period time to expire before you perform a new cycle. If the secondary
change volume is unconfigured when the background copy completes, the relationship stops as if
there is no cycle period.
Relationships that are
active-active must have a state of idling to be started. (You
must specify -primary to determine which of the master and auxiliary copies
become the primary when you start an idling relationship.)
Use this command to:
- Restart the active-active relationship copy process and retain the
historical disaster recovery copy that access is granted to (which might be used while the
up-to-date copy was offline)
- Switch back to an up-to-date copy in the same state it was in before you specify
stoprcrelationship -access. Any changes that are made to the historical copy
are discarded
Remember: If you switch back to the up-to-date copy, you might have to take
host actions to prepare for the volume data that changes.
After you specify this
command, if the secondary copy is not a historical copy of the primary relationship, it cannot
be used for disaster recovery (and disaster recovery availability is restored after the copies
are resynchronized). This situation can occur when:
- The new primary is the historical copy, which means the new secondary copy contains data
that is from a later point in time than the data that the primary contains
- The secondary copy is the historical copy and is modified between specifying
stoprcrelationship -access and startrcrelationship -primary
command (which means the secondary copy represents a divergent data image)
This command copies only the regions that are needed to resynchronize the two copies.