Metro Mirror and Global Mirror relationships

Metro Mirror and Global Mirror relationships define the relationship between two volumes: a master volume and an auxiliary volume.

Typically, the master volume contains the production copy of the data and is the volume that the application normally accesses. The auxiliary volume typically contains a backup copy of the data and is used for disaster recovery.

Global Mirror with cycling also use change volumes, which hold earlier consistent revisions of data when changes are made. A change volume can be created for both the master volume and the auxiliary volume of the relationship.

The master and auxiliary volumes are defined when the relationship is created, and these attributes never change. However, either volume can operate in the primary or secondary role as necessary. The primary volume contains a valid copy of the application data and receives updates from the host application, analogous to a source volume. The secondary volume receives a copy of any updates to the primary volume because these updates are all transmitted across the mirror link. Therefore, the secondary volume is analogous to a continuously updated target volume. When a relationship is created, the master volume is assigned the role of primary volume and the auxiliary volume is assigned the role of secondary volume. Therefore, the initial copying direction is from master to auxiliary. When the relationship is in a consistent state, you can reverse the copy direction.

Usually, the two volumes in a relationship must be the same size. However, in some cases, the volume size can be changed. For more information, see Expanding volumes by using the CLI.When the two volumes are in the same system, they must be in the same I/O group.

If change volumes are defined, they must be the same size and in the same I/O group as the associated master volume or auxiliary volume.

For ease of application management, a relationship can be added to a consistency group.

Note: Membership of a consistency group is an attribute of the relationship, not the consistency group. Use the chrcrelationship command to add a relationship to, or remove a relationship from, a consistency group.

Copy types

A Metro Mirror copy ensures that updates are committed to both the primary and secondary volumes before confirmation of the I/O completion is sent to the host application. This behavior ensures that the secondary volume is synchronized with the primary volume when a failover operation is performed.

A Global Mirror copy allows the host application to receive confirmation of I/O completion before the updates are committed to the secondary volume. If a failover operation is performed, the host application must recover and apply any updates that were not committed to the secondary volume.

A multiple-cycling Global Mirror copy reduces bandwidth requirements by addressing only the average throughput and not the peak. The copying process for multiple-cycling Global Mirror is similar to Metro Mirror and noncycling Global Mirror. The change volume for the secondary volume can be used to maintain a consistent image at the secondary volume while the background copy process is active. Multiple-cycling Global Mirror relationships have a higher recovery point objective (RPO) than noncycling Global Mirror relationships.

States

When a Metro Mirror or Global Mirror relationship is created with two volumes in different systems, the distinction between the connected and disconnected states is important. These states apply to systems, the relationships, and the consistency groups.

To review the state of the relationships, you can use the management GUI or issue the lsrcconsistgrp or lsrcrelationship commands. The following relationship states are possible:
InconsistentStopped
The primary volume is accessible for read/write I/O operations, but the secondary volume is not accessible for either operation. A copy process must be started to make the secondary volume consistent.
InconsistentCopying
The primary volume is accessible for read/write I/O operations, but the secondary volume is not accessible for either operation. This state is entered after a startrcrelationship command is issued to a consistency group in the InconsistentStopped state. This state is also entered when a startrcrelationship -force command is issued to a consistency group that is in the Idling or ConsistentStopped state.
ConsistentStopped
The secondary volume contains a consistent image, but it might be out of date with the primary volume. This state can occur when a relationship was in the ConsistentSynchronized state and experiences an error that forces a freeze of the consistency group. This state can also occur when a relationship is created with the CreateConsistentFlag parameter set to TRUE.
ConsistentSynchronized
The primary volume is accessible for read and write I/O operations. The secondary volume is accessible for read-only I/O operations.
ConsistentCopying
The primary volume is accessible for read/write I/O operations. The secondary volume contains a consistent image, which might be out of date with the primary volume, and is accessible for read-only I/O operations. If the relationship is a multiple-cycling Global Mirror relationship, the secondary volume periodically refreshes with an up-to-date consistent image.
Idling
The master volume and the auxiliary volume operate in the primary role. Both volumes are accessible for read/write I/O operations. This state occurs when the relationship stops; it specifies that write access is allowed to the secondary volume.
IdlingDisconnected
All volumes in this half of the consistency group are operating in the primary role and can accept read or write I/O operations.
InconsistentDisconnected
All volumes in this half of the consistency group are operating in the secondary role and cannot accept read or write I/O operations.
ConsistentDisconnected
All volumes in this half of the consistency group are operating in the secondary role and can accept read I/O operations but not write I/O operations.

Status

The system also provides additional information about the status of the volume relationships. To view the status, issue the lsrcconsistgrp or lsrcrelationship command.

online
All volumes in the relationship are online and accessible. If the state of the relationship is ConsistentSynchronized, ConsistentCopying, or InconsistentCopying, the volumes can replicate the host I/O write operations that are received on the primary volume.
primary_offline
The primary volume of the relationship is offline, which prevents additional host I/O operations. Synchronization is paused until the primary volume is online again.
secondary_offline
The secondary volume of the relationship is offline. For regular Global Mirror relationships in ConsistentSynchronized state (that is, Global Mirror without change volumes) and Metro Mirror relationships, more I/O write operations to the primary volume stop the relationship.
io_channel_offline
The remote system is not accessible. For regular Global Mirror relationships in ConsistentSynchronized state (that is, Global Mirror without change volumes) and Metro Mirror relationships, more I/O write operations to the primary volume stop the relationship.
primary_change_offline
The primary change volume of the relationship is offline. For Global Mirror with change volumes relationships, the current I/O cycle ends; a new I/O cycle begins when the primary change volume goes online again.
secondary_change_offline
The secondary change volume of the relationship is offline. For Global Mirror with change volumes relationships, the current I/O cycle is paused; when the secondary change volume goes online again, the I/O cycle resumes.
change_volumes_needed
For Global Mirror with change volumes relationships, at least one change volume is not yet configured. In this status, replication is prevented.