In order for the data to be consistent, the deposit of the paycheck must be applied before the withdrawal of cash for each of the checking accounts. However, it does not matter whether the deposit to checking account A or checking account B occurred first, as long as the associated withdrawals are in the correct order. So for example, the data copy would be
consistent if the following sequence occurred at the copy. In other words, the order of updates is not the same as it was for the source data, but the order of dependent writes is still
preserved.
1.Deposit paycheck in checking account B
2.Deposit paycheck in checking account A
3.Withdraw cash from checking account B
4.WIthdraw cash from checking account A
How does Consistency Group keep data consistency?
Consistency Group operations cause the storage units to hold I/O activity to a volume for a time period by putting the source volume into an extended long busy state. This operation can be done across multiple LUNs or volumes, and even across multiple storage units.
In the storage subsystem itself, each command is managed with each logical subsystem
(LSS). This means that there are slight time lags until each volume in the different LSS is changed to an extended long busy state. Some people are concerned that the time lag causes
you to lose data consistency, but, it is not true. We explain how to keep data consistency in the Consistency Group environments in the following section.
See Figure
.
Servers
1st
2nd
3rd
dependency for each write operation
| LSS11 |
Wait | This write operation is |
not completed because | |
| of extended long busy |
| condition. |
LSS12
Wait
These write operations are not completed
LSS13 because 1st write operation is not 
completed.
Wait
Figure 6-12 Consistency Group: Example 1
106DS6000 Series: Concepts and Architecture
