startrcrelationship

Use the startrcrelationship command to start the Metro Mirror or Global Mirror relationship copy process, set the direction of copy if undefined, and (optionally) mark the secondary volume of the relationship as clean. The relationship must be a stand-alone relationship. You can also use this command to restart the active-active relationship copy process after specifying stoprcrelationship -access.

Syntax

startrcrelationship [ -primary { master | aux } ] [ -force ] [ -clean ] { rc_rel_id | rc_rel_name }

Parameters

-primarymaster | aux
(Optional) Specifies the copy direction by defining whether the master or auxiliary disk becomes the primary (source). This parameter is required when the primary is undefined if, for example, the relationship is in the idling state.
-force
(Optional) Specifies that you want the system to process the copy operation even if it might lead to a temporary loss of consistency while synchronization occurs. This parameter is required if the relationship is in the ConsistenStoppes state, but is not synchronized or in idling state, but is not synchronized.
Important: Using the force parameter might result in a loss of access. Use it only under the direction of your product support information.
-clean
(Optional) Specifies that the volume that is to become a secondary is clean. Any changes that are made on the secondary volume are ignored, and only changes made on the clean primary volume are considered when synchronizing the primary and secondary disks. The relationship must be in an Idling (connected) state for this parameter to work.
Attention: This flag should be used only if all data changed on the secondary volumes while the consistency group was in the idling state matches the state of the primary volumes when the consistency group was stopped. Otherwise, relationships that are not consistent are reported as consistent. When this is completed there is no method to determine whether these volumes ever reach a true consistent state until a full background copy can be carried out again.
rc_rel_id | rc_rel_name
(Required) Specifies the ID or name of the relationship that you want to start in a stand-alone relationship.

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.

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 with -access specified 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 and -access is specified
  • 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 has been received at the secondary volume, the -force flag is still 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.
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 creating a background copy the relationship remains in copying state, waiting for the remainder of the period time to expire before performing 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 starting an idling relationship.)

Use this command to:
  • Restart the active-active relationship copy process and retain the historical disaster recovery copy that access has been granted to (which might have been used while the up-to-date copy was offline)
  • Switch back to an up-to-date copy in the same state it was before stoprcrelationship -access was specified. 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 changing.
After specifying 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 was modified between the specification of 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.

An invocation example

startrcrelationship rccopy1

The resulting output: 

No feedback
Parent topic: Copy services commands