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 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.
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.
- 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.
- 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.
- 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.
- The primary volume is accessible for read and write I/O operations. The secondary volume is accessible for read-only I/O operations.
- 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.
- 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.
- All volumes in this half of the consistency group are operating in the primary role and can accept read or write I/O operations.
- All volumes in this half of the consistency group are operating in the secondary role and cannot accept read or write I/O operations.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- For Global Mirror with change volumes relationships, at least one change volume is not yet configured. In this status, replication is prevented.