06-29-2012 05:39 AM
Environment
OS = Windows 2008R2
Storage Foundation version = 5.1 SP2
Where can I verify in SF/VVR for windows that the data is consistent as we can verify via the below command in Linux:
vradmin -g DiskGroup repstatus RVGname
Solved! Go to Solution.
06-30-2012 03:31 AM
Yes RLINK is up to date means data is consistent and if replication is not up to date and using SRL then it is still consistent, just the data is behind. And when DCM is being used, but NOT replaying, then data is also consistent (but behind). Data is only inconsistent during DCM replay.
Lets look at a simple example:
Data at
Time 0:
Primary Secondary A B C A B C D E F D E F
Then you change a block (to Z) and this is in SRL and not at secondary, but the Secondary is still consistent, it is just behind as it represents the primary at time 0
Time 1:
Primary Secondary SRL Z B C A B C Z D E F D E F
Then you change another block (to Y) and this is in SRL and not at secondary, but the Secondary is still consistent, it is just behind as it represents the primary at time 0
Time 2:
Primary Secondary SRL Z B Y A B C Z D E F D E F Y
Time 3:
Primary Secondary SRL Z B Y Z B C Y D E F D E F
Then another block is written (V) and this fills SRL and so DCM is used (1 is dirty, 0 is clean) - Secondary is still consistent, it is just behind as it represents the primary at time 1
Time 4:
Primary Secondary DCM Z B Y Z B C 0 0 1 V E F D E F 1 0 0
A futher block is writen (W), but the secondary will not change as when DCM is being used, manual intervention is requied to start DCM play as DCM replay will make secondary inconsistent, but at the moment Secondary is still consistent, it is just behind as it represents the data at time 1
Time 5:
Primary Secondary DCM Z W Y Z B C 0 1 1 V E F D E F 1 0 0
And another block is writen (T) and secondary is still consistent.
Time 6:
Primary Secondary DCM Z W T Z B C 0 1 1 V E F D E F 1 0 0
Time 7:
Primary Secondary DCM Z W T Z W C 0 0 1 V E F D E F 1 0 0
Note here the primary never, at ANY time had the first 3 blocks as "Z W C", so the secondary is inconsistent, so in the real world this represents corrupt data. DCM continues to replay and writes "T" and secondary remains inconsistent:
Time 8:
Primary Secondary DCM Z W T Z W T 0 0 0 V E F D E F 1 0 0
Note here the primary never, at at any time had the first 4 blocks as "Z W T D", so the secondary is still inconsistent, DCM continues to replay and completes and so now secondary is up to date and consistent:
Time 9:
Primary Secondary Z W T Z W T V E F V E F
Hope this makes "up to date", "consistent and behind" and inconsistent clear.
Mike
06-29-2012 05:55 AM
You can use:
vxrlink -f DiskGroup status rlink_name
You can get rlink name from "vxprint -P"
This check if replication is up to data or if behind and using SRL or DCM. If it shows DCM is replaying then data is inconsistent which should be the only time the data is inconsistent.
You can use vxrsync to actually check volumes are the same (see comment https://www-secure.symantec.com/connect/forums/i-have-mirrored-data-between-two-sotrage#comment-7321... for more details on this)
Mike
06-30-2012 02:03 AM
Thanks for your kind words mike. But its -g instead of -f
C:\Users\Administrator>vxrlink -g TechServerDG status PR
6/29/2012 7:05:12 AM
RLINK is up to date.
(RLINK is up to date means data is consistent ?)
========
One more thing I would like to add here that we have to use the Primary rlink name not secondary rlink name.
06-30-2012 03:31 AM
Yes RLINK is up to date means data is consistent and if replication is not up to date and using SRL then it is still consistent, just the data is behind. And when DCM is being used, but NOT replaying, then data is also consistent (but behind). Data is only inconsistent during DCM replay.
Lets look at a simple example:
Data at
Time 0:
Primary Secondary A B C A B C D E F D E F
Then you change a block (to Z) and this is in SRL and not at secondary, but the Secondary is still consistent, it is just behind as it represents the primary at time 0
Time 1:
Primary Secondary SRL Z B C A B C Z D E F D E F
Then you change another block (to Y) and this is in SRL and not at secondary, but the Secondary is still consistent, it is just behind as it represents the primary at time 0
Time 2:
Primary Secondary SRL Z B Y A B C Z D E F D E F Y
Time 3:
Primary Secondary SRL Z B Y Z B C Y D E F D E F
Then another block is written (V) and this fills SRL and so DCM is used (1 is dirty, 0 is clean) - Secondary is still consistent, it is just behind as it represents the primary at time 1
Time 4:
Primary Secondary DCM Z B Y Z B C 0 0 1 V E F D E F 1 0 0
A futher block is writen (W), but the secondary will not change as when DCM is being used, manual intervention is requied to start DCM play as DCM replay will make secondary inconsistent, but at the moment Secondary is still consistent, it is just behind as it represents the data at time 1
Time 5:
Primary Secondary DCM Z W Y Z B C 0 1 1 V E F D E F 1 0 0
And another block is writen (T) and secondary is still consistent.
Time 6:
Primary Secondary DCM Z W T Z B C 0 1 1 V E F D E F 1 0 0
Time 7:
Primary Secondary DCM Z W T Z W C 0 0 1 V E F D E F 1 0 0
Note here the primary never, at ANY time had the first 3 blocks as "Z W C", so the secondary is inconsistent, so in the real world this represents corrupt data. DCM continues to replay and writes "T" and secondary remains inconsistent:
Time 8:
Primary Secondary DCM Z W T Z W T 0 0 0 V E F D E F 1 0 0
Note here the primary never, at at any time had the first 4 blocks as "Z W T D", so the secondary is still inconsistent, DCM continues to replay and completes and so now secondary is up to date and consistent:
Time 9:
Primary Secondary Z W T Z W T V E F V E F
Hope this makes "up to date", "consistent and behind" and inconsistent clear.
Mike
06-30-2012 05:23 AM
Mike definately this is very nice even the second last was also helpfull text.
I just stuck to see the word consistent which I am used to see in linux as the below snap shows: (Although I understood your words above with bundle of thanks and should be awarded +thumbs )
06-30-2012 05:40 AM
Basically with VVR, you should never be inconsistent, unless you manually did something - i.e you should not get inconsistent automatically and you only get inconsistent when you manually sync the DCM (after SRL overflow or after a VVR takeover), so it is advisable to take a snapshot at secondary before syncing DCM in case primary fails before DCM sync is complete ( a consistent, but behind copy is better than an inconsistent copy). The only reason you should become inconsistent automatically is if you set AutoResync attribute of the VCS RVGPrimary agent to the NON-default value of 1 (if you set to 1 then VCS runs the DCM sync when the old primary comes back).
Mike
06-30-2012 06:33 AM
Hmmm thanks for your kind words again mike :)