Metro Mirror Volume State; Data Consistency - IBM System storage DS6000 Series Redbook

12.2 Metro Mirror volume state

Volumes participating in a Metro Mirror session can be found in any of the following states:
Copy pending: volumes are in
established, but the primary and secondary volumes are still out of sync. In that case, data
still needs to be copied from the primary to the secondary volume of the Metro Mirror pair.
This may be the case immediately after a relationship is initially established, or
reestablished after being suspended. The Metro Mirror secondary volume is not
accessible when the pair is in copy pending state.
Full duplex: a volume copy pair is in
is, both primary and secondary volumes contain exactly the same data. The secondary
volume is not accessible when the pair is in full duplex.
Suspended: volumes are in the
subsystems cannot communicate anymore, or when the Metro Mirror pair is suspended
manually. In this state, writes to the primary volume are not mirrored onto the secondary
volume. The secondary volume becomes out of sync.
During this time, Metro Mirror keeps a bitmap record of the changed tracks in the primary
volume. Later, when the volumes are resynchronized, only the tracks that were updated
will be copied.
Target copy pending: indicates that the primary volume is unknown or cannot be queried
and the secondary state is copy pending.
Target full-duplex: indicates that the primary volume is unknown or cannot be queried and
the secondary state is full duplex.
Target suspended: indicates that the primary volume is unknown or cannot be queried and
the secondary state is suspended.
Not remote copy pair: indicates that the relationship is not a Metro Mirror pair.
Invalid-state: indicates that the relationship state is invalid.

12.3 Data consistency

In order to restart applications at the remote site successfully, the remote site volumes must
have consistent data. In normal operation, Metro Mirror keeps data consistency at the remote
site. However, in case of a rolling disaster type of situation, a certain mechanism is necessary
to keep data consistency at the remote site.
For Metro Mirror, consistency requirements are managed through use of the
Group
option. You can specify this option when you are defining Metro Mirror paths between
pairs of LSSs or when you change the default LSS settings. Volumes or LUNs that are paired
between two LSSs whose paths are defined with the Consistency Group option can be
considered part of a Consistency Group.
Consistency is provided by means of the
systems) conditions. These are triggered when the DS6000 detects a condition where it
cannot update the Metro Mirror secondary volume. The volume pair that first detects the error
will go into the extended long busy condition, such that it will not do any writes. For z/OS, a
system message will be issued (IEA494I state change message); for open systems, an
SNMP trap message will be issued. These messages can be used as a trigger for automation
purposes that will provide data consistency.
copy pending
state after the Metro Mirror relationship is
full duplex
state when its members are in sync; that
suspended
state when the primary and secondary storage
extended long busy
Chapter 12. Metro Mirror overview
Consistency
queue full
(for z/OS) or (for open
131