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 svc_expandvdiskstask_22fift.html.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.