cancel
Showing results for 
Search instead for 
Did you mean: 

Where can I verify "Consistent data" under VVR

Zahid_Haseeb
Moderator
Moderator
Partner    VIP    Accredited

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

1 ACCEPTED SOLUTION

Accepted Solutions

mikebounds
Level 6
Partner Accredited

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
Then the replication starts to catch up - it knows Z was writen first so the secondary is updated and is consistent, it is just behind as it represents the primary at time 1

 

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
Then DCM replay is started, but DCM cannot record the order of writes so now the secondary becomes inconsistent as it writes "W" first and this was NOT the next block that was written on Primary:

 

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

View solution in original post

6 REPLIES 6

mikebounds
Level 6
Partner Accredited

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

Zahid_Haseeb
Moderator
Moderator
Partner    VIP    Accredited

Thanks for your kind words mike. But its -g instead of -f   wink

 

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. 

 

 

mikebounds
Level 6
Partner Accredited

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
Then the replication starts to catch up - it knows Z was writen first so the secondary is updated and is consistent, it is just behind as it represents the primary at time 1

 

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
Then DCM replay is started, but DCM cannot record the order of writes so now the secondary becomes inconsistent as it writes "W" first and this was NOT the next block that was written on Primary:

 

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

Zahid_Haseeb
Moderator
Moderator
Partner    VIP    Accredited

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 smiley )

mikebounds
Level 6
Partner Accredited

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

 

Zahid_Haseeb
Moderator
Moderator
Partner    VIP    Accredited

Hmmm thanks for your kind words again mike :)