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 you specify 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 ConsistentStopped state, but is not synchronized or in idling state - except if consistency protection is configured.
Important: Using the force parameter might result in a loss of access. Use it only under the direction of IBM support personnel.
-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, but 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 must 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 completes, 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.

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.

An invocation example

startrcrelationship rccopy1

The resulting output:

No feedback