[Veritas-ha] VVR 3.2 question

[Eric Feng Jie]

Hi, Brooks,

I'm puzzled again after I did a autosyn test. My conclusion is cksum does not report the same even through primary and secondary are in syn, after automatic synchronization. When you talk about same bit-pattern, you don't really mean bit-by-bit-identical, as required by force synchronization (-f startrep)? Here's my test result

7. synchronizing the secondary (automatic synchronization)
Primary:
# vradmin -a startrep replrvg sgldsd01
Messages from Primary :
vxvm:vxrlink: WARNING: Attaching rlink to non-empty rvg. Autosync will be performed.
vxvm:vxrlink: INFO: Secondary data volumes detected with rvg replrvg as parent:
vxvm:vxrlink: INFO: replvol:      len=4194304  primary_datavol=replvol
vxvm:vxrlink: INFO: Autosync operation has started
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is in AUTOSYNC. 2072576 Kbytes remaining.
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is in AUTOSYNC. 2053408 Kbytes remaining.
#
...
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is up to date

NOTE: synchronization time is proportional to size of volume (2g = 1/2hr)

8. verifying secondary is in syn
Primary:
# vradmin stoprep replrvg sgldsd01

vradmin: WARNING: Secondary data volumes will become out-of-date.
vradmin: Continue with stoprep (y/n)? y
# vxrlink status 69_to_122
vxvm:vxrlink: INFO: Rlink 69_to_122 is not currently attached (STALE).
#
# cksum /dev/vx/rdsk/rootdg/replvol
3089107577      2147483648      /dev/vx/rdsk/rootdg/replvol
#
It took about 5 minutes to finish.

Secondary:
# vxrvg start replrvg
# cksum /dev/vx/rdsk/rootdg/replvol
729953647       2147483648      /dev/vx/rdsk/rootdg/replvol
#
# vxrvg stop replrvg
#

Resuming replication, this is a bit risky because I use -f startrep due to the fact that 'vxrlink status' had reported two volumes are in syn (rlink status up-to-date).
Primary:
# vradmin -f startrep replrvg sgldsd01
Messages from Primary :
vxvm:vxrlink: WARNING: Attaching rlink to non-empty rvg. No checkpoint parameter supplied.
vxvm:vxrlink: INFO: Secondary data volumes detected with rvg replrvg as parent:
vxvm:vxrlink: INFO: replvol:      len=4194304  primary_datavol=replvol
# umount /replvol
# vradmin migrate replrvg sgldsd01

vradmin: WARNING: Make sure applications using primary data volumes are stopped.
vradmin: Continue with migrate (y/n)? y
#

Secondary:
# mount /replvol
# ls /replvol
lost+found           sgldmd01_config.txt  smc898
ps_data              sh3530
#

Succeed! NOTE: checksum is no longer valid when autosyn? If it is not, what should I do to verify primary and secondary are in syn?


Thanks
Eric

----- Original Message ----- 
  From: Brooks Graham 
  To: 'Eric Feng Jie' ; Gene Henriksen ; veritas-ha at mailman.eng.auburn.edu ; Brooks Graham 
  Sent: Friday, October 26, 2001 2:46 AM
  Subject: RE: [Veritas-ha] VVR 3.2 question


  Okay, after re-reading your initial post more carefully, I see that you've missed a very, very important step: Initialization.
   
  Bear with me as this might end up being quite wordy.
   
  The basic philosophy behind VVR is to take volume images that are being used for production I/O (the primary) and replicate those images in such a way as to have identical volume images maintained at a remote location (the secondary).  Now remember that in VERITAS Volume Manager, the volume images that are managed by VxVM simply contain a pattern of bytes that have some meaning to a higher-level application such as a filesystem (VxFS, for example).  VxVM has no knowledge of what those byte patters represent - it's up to the higher-level application to do that.  VxVM's role is to manage the layout/configuration of those virtual devices we call volumes.  The filesystem's role is to place structures down on those volumes and implement a common way to access data (files).  One way I keep this straight is to remember that a volume is never full or empty, it's just a bit-pattern.  Filesystems get full or can be empty.  
   
  Now, with VVR, when we set up a VVR configuration, we start out with a set of primary volumes and we make an identical set of volumes on the secondary (their names and sizes must *exactly* match).  Before we can begin the process of real-time replication, we must make the secondary volume images match the primary.  When I say that, I really mean that we must make the bit-patterns of the secondary volumes match the bit patterns of the primary volumes.  We call this process "initialization" or "initial synchronization."  We give you many choices on how to accomplish this including a feature we call "Autosync."  This will take live, primary volumes and move their bit-patterns over to their corresponding secondary volumes over the IP network.  This works well for either/or small data sets or large pipes (100BT, for example).
   
  Looking at your procedure, it appears that you executed a "force attach" of the secondary without initializing (vradmin -f att ...)  While this appeared to work, it does not make the bit-patterns match, it simply starts moving any subsequent updates over to the secondary.  This left you with secondary volumes that were not usable.  Note that the "-f" option of *any* VxVM command can be very dangerous.  We try and tell you when a requested operation is not possible, but that warning can be overridden in most cases with "-f".  The results are then unpredictable at best.  In terms of VVR, the "force attach" command really means that you're telling VxVM/VVR that *you* know that the bit-patterns of all the volumes in the rvg match *exactly* even if VVR does not.  There are times when this is appropriate, just not usually for initialization purposes.
   
  [I couldn't tell if you did a mkfs on the secondary volumes or not, but you don't need to.  When you correctly initialize secondary volumes, the bit-patters which represent the filesystem structures are moved along with everything else.]
   
  To do an Autosync, if you don't already have them, attach DCM logs to each data volume in the rvg (not the SRL) by doing something like "vxassist -g <dgname> addlog <volume_name> logtype=dcm".  Then execute "vradmin -a startrep ..."
   
  Hope that helps clear up any confusion.
   
  Please let me know if you have any further questions or if I can help in any other way.
   
  -bdg

  [Brooks Graham] 
   
   
   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.eng.auburn.edu/pipermail/veritas-ha/attachments/20011026/19cb6b0b/attachment.htm