IBM XIV Storage System Copy Services and Migration

uncommitted data, and it is the responsibility of the secondary peer to synchronize theseupdates to primary peer.Reconnection when both sides have the same roleSituations where both sides are configured to the same role can only occur when one sidewas changed. The roles must be changed to have one master and one slave (volume orconsistency group). Change the volume roles as appropriate on both sides before the link isresumed.If the link is resumed and both sides have the same role, the coupling will not becomeoperational. To solve this problem, the user must use the change role function on one of thevolumes and then activate the coupling.5.4 Resynchronization after link failureWhen synchronization between the peers has been interrupted, for example, by a failure of alllinks or the pairs have been suspended by a command, you probably want to resume themirroring after the problems were solved.Resynchronization can be performed in any direction given that one peer has the master roleand the other the slave role. When there is a temporary failure of all links from the primary XIVto the secondary XIV, you re-establish the mirroring in the original direction after the links areup again.Also, if you suspended mirroring for a disaster recovery test at the secondary site, you mightwant to reset the changes made to the secondary site during the tests and re-establishmirroring from the primary to the secondary site.If there was a disaster and production is now running on the secondary site, re-establishmirroring first from the secondary site to the primary site and later on switch mirroring to theoriginal direction from the primary XIV to the secondary XIV.In any case, the slave peers usually are in a consistent state up to the moment whenresynchronization starts. During the resynchronization process, the peers (volumes orconsistency group) are inconsistent. To preserve consistency, the XIV at the slave sideautomatically creates a snapshot of the involved volumes or, in case of a consistency group, asnapshot of the entire consistency group before transmitting any data to the slave volumes.5.4.1 Last consistent snapshotBefore a resynchronization process is initiated, a snapshot of the slave volumes orconsistency groups is created. A snapshot is created to ensure the usability of the slavevolumes/CG in case of a primary site disaster during the resynchronization process. If themaster volume/CG is destroyed before resynchronization is completed, the slave volume/CGmight be inconsistent because it might have been only partially updated with the changes thatwere made to the master volume. To handle this situation, the secondary XIV always createsa snapshot of the last consistent slave volume/CG after reconnecting to the secondary XIVand before starting the resynchronization process. No snapshot is created for couplings thatare in the initialization state. The snapshot is preserved until a volume pair is synchronizedagain, or in case of remote mirror consistency groups, until all volumes of the consistencygroup are synchronized.136 IBM XIV Storage System: Copy Services and Migration