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 lowers bandwidth
requirements by only addressing 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 has
stopped, which 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 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, additional I/O write operations to the primary volume will 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, additional I/O write operations to the primary
volume will 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.