Where can I verify "Consistent data" under VVR
Created: 29 Jun 2012 | Updated: 01 Aug 2012 | 6 comments
This issue has been solved. See solution.
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
Discussion Filed Under:
Comments 6 Comments • Jump to latest comment
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-7321431 for more details on this)
Mike
UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows
If this post has helped you, please vote or mark as solution
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.
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
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:
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:
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:
Time 3:
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:
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:
And another block is writen (T) and secondary is still consistent.
Time 6:
Time 7:
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:
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:
Hope this makes "up to date", "consistent and behind" and inconsistent clear.
Mike
UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows
If this post has helped you, please vote or mark as solution
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
)
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
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
UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows
If this post has helped you, please vote or mark as solution
Hmmm thanks for your kind words again mike :)
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
Would you like to reply?
Login or Register to post your comment.