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.
The two volumes in a relationship must be the
same size. 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.