Description
This command creates a new Global
Mirror, Metro Mirror, or active-active relationship. A Metro Mirror
relationship defines the relationship between two volumes. One volume is a master volume and the
other volume is an auxiliary volume. This relationship persists until deleted. The auxiliary
volume must be identical in size to the master volume or the command fails. This command also
returns the new relationship ID.
The master and auxiliary cannot be in an existing relationship. Any defined FlashCopy mappings that have the proposed master volume as the
target of the FlashCopy mapping must be using the
same I/O group as the master volume. Any defined FlashCopy mappings that have the proposed auxiliary volume as the target of the FlashCopy mapping must be using the same I/O group as
the auxiliary volume.
Note: You cannot create a remote copy relationship with this command if
the auxiliary volume is an active FlashCopy mapping
target. If the I/O group has enough bitmap
space available to allocate for remote copy and the allocated space for the remote copy is not
large enough to accommodate the new relationship, space is automatically added. (Remote copy
includes Global Mirror, Metro Mirror, and active-active
relationships.)
Note: You cannot use this command if cloud snapshot is
enabled on the volume or the volume owner type is cloud_backup.
Metro
Mirror relationships use one of the following copy types:
- A Metro Mirror copy ensures that updates are committed to both the primary and secondary
volumes before the copy sends confirmation of I/O completion to the host application. This
ensures that the secondary volume is synchronized with the primary volume if 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.
You can optionally give the relationship a name. The name must be a unique
relationship name across both systems.
The relationship can optionally be assigned to a
consistency group. A consistency group ensures that a number of relationships are managed so if
the relationships disconnect, the data in all relationships within the group is in a consistent
state. For example, the state can be important in a database application where data files and
log files are stored on separate volumes and consequently are managed by separate relationships.
Remember: In the event of a disaster, the primary and secondary sites might become
disconnected.
As the disconnection occurs and the relationships stop copying data from
the primary to the secondary site, there is no assurance that updates to the two separate
secondary volumes stop in a consistent manner if the relationships that are associated with the
volumes do not belong to a consistency group.
For proper database operation, it is
important that updates to the log files and the database data are made in a consistent and
orderly fashion. It is crucial in this example that the log file volume and the data volume at
the secondary site are in a consistent state. This can be achieved by putting the relationships
that are associated with these volumes into a consistency group. Both Metro Mirror and Global
Mirror processing ensure that updates to both volumes at the secondary are stopped, leaving a
consistent image based on the updates that occurred at the primary site.
If you specify a
consistency group, both the group and the relationship must are created by using the same master
system and the same auxiliary system. The relationship must not be a part of another consistency
group. If the consistency group is empty, it acquires the type of the first relationship that is
added to it. Therefore, each subsequent relationship that you add to the consistency group must
have the same type.
If the consistency group is not empty, the consistency group and the
relationship must be in the same state. If the consistency group is empty, it acquires the state
of the first relationship that is added to it. If the state has an assigned copy direction, the
direction of the consistency group and the relationship must match that direction.
If you
do not specify a consistency group, a stand-alone relationship is created.
If you specify
the -sync parameter, the master and auxiliary volumes contain identical
data at the point when the relationship is created. You must ensure that the auxiliary is
created to match the master and that no data movement occurs to either volume before you issue
the mkrcrelationship command.
If you specify the
-global parameter, a Global Mirror relationship is created. Otherwise, a
Metro Mirror relationship is created instead.
The volumes that are specified on the
-master and -aux parameters cannot be master or auxiliary
volumes in an existing relationship.
If you specify
-activeactive:
- The system that is specified with -cluster must be the local
system.
- -global must not be specified.
- The volume that is specified with -master must:
- Be in an I/O group with both nodes that have the same site name and site ID
- Have all volume copies stored in storage pools in the same site as the volume's I/O
group
- Not be the target of a FlashCopy mapping
- Not be the source of any FlashCopy mappings
to volumes in a different site or by using bitmap memory from nodes in a different site (but
the volume can be the source of a FlashCopy
mapping in which the target volume and map are in the same site)
- The volume that is specified with -aux must:
- Be part of an I/O group with a different site ID and site name than the master volume
(with no volume host mappings that are defined)
- Have all volume copies stored in storage pools in the same site as the volume's I/O
group
- Not be the target of a FlashCopy mapping
- Not be the source of any FlashCopy mappings
to volumes in a different site or by using bitmap memory from nodes in a different site (but
the volume can be the source of a FlashCopy
mapping in which the target volume and map are in the same site)
Access the data stored on these volumes by accessing the volume you specify using the
-master parameter. Both I/O groups of the volumes that are specified by
the
-master and
-aux parameters have a local physical
copy and cache, allowing access (by using the master volume ID) whether the auxiliary volume's
site is available or
not.
Remember: This command cannot be used on a volume that is owned by a file
system.