Do we need fbsync can do a complete sync if Primary Site Disk fails

[Zahid_Haseeb]

Environment

OS = rhel 5

SGHA/DR version = 5.0 MP3 RP3

Primary Site = Two Nodes

DR Site = Single Node

Disk Group = one (with four SAN Disks)

Work Performed

My Primary Site's two SAN Disk from four DIsks which was shared between both Nodes failed. Now my Application was DOWN at Primary Site So I UP my Application from DR Site successfully. Now at Primary Site I replaced both bad Disks with the two new DIsks via using option 4 and 5 of vxdiskadm command successfully. Now from DR Site I ran the fbsync command which started successfully.

My question :

I ran the fbsync command .. This I did right or wrong ? (as this is not a partial sync and has to sync complete as my Primary Site have fresh Disks. I think that fbsync do a incremental Sync)  OR fbsync can also SYNC complete data from DR Site to Primary in my case ?

Comments Required please

[Zahid_Haseeb]

I have found a TN as per my point # 1 concern. This make me feel that we can copy the DiskGroup Resource from Application ServiceGroup to Replication ServiceGroup and after copied+Resources dependencies created at Replication ServiceGroup, we can delete the DiskGroup Resource from Application ServiceGroup.

https://sort.symantec.com/public/documents/sf/5.1/aix/html/vcs_admin/ch_vcs_globalcluster23.html#no_figure_caption0

[mikebounds]

I tried mounting a volume in secondary RVG on my VMWare 5.1GA RHEL5 setup and it mounted an ext3 filesystem read-only without any issues when I had a consistent rlink.  When my rlink was inconsistent, then it would not mount and I got a vxio error "Failing reads on rvg", followed by the errors you get.  So as long as your rlink is consistent, which it should be if you have just run a stoprep and startrep and autosync has finished, then you should be able to mount filesystem readonly.  If rlink is inconsistent, then you won't be able to do a snapshot either as the RVG disables the reads, BUT if you detach the rlink (by vxrlink det or vradmin stoprep), then you can read AND write to your volumes so you should be able to mount normally after stopping replication.  Maybe something works different in 5.0MP3, but you can check if you can read from your volume using dd:
dd if=/dev/vx/dsk/DG/vol count=1 of=/dev/null

This should alway work on volumes on your secondary RVG unless rlink is inconsistent and attached.  If your rlink is consistent OR detached, then reads should work.

I am not sure what the point is in recreating VCS objects as your issue is with VVR, not VCS.  Removing resources from VCS does not offline the resource and you can move a resource in GUI by copy,delete,paste.

Mike

[Zahid_Haseeb]

FIrst thanks alot to all

Ahh as recreating the vcs resources, actually i rename the DG, volume, resources name

I recreated as all the shared plan. Now all things fine. What I have come to know in last day which me and Support both forgetting. I saw when the RVG was is recovery state I was not able to mount volume. Simple..But I did nt remember when initially both sites fine and replication was consistent and up to date at that time what is the state of RVG (definately at that time it should be Enable)

[mikebounds]

So can you mount volume read-only at the secondary now?

Mike

[Zahid_Haseeb]

I left premises when the Replication started(which was expected to take 2 hours). I will check by Monday and share with you the result

[Zahid_Haseeb]

No not yet :(

See the below :

Primary Site (Real Primary)

# mount

/dev/sdg3 on / type ext3 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

/dev/sdg2 on /var type ext3 (rw)

/dev/sdg1 on /boot type ext3 (rw)

tmpfs on /dev/shm type tmpfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

tmpfs on /dev/vx type tmpfs (rw,size=4k,nr_inodes=2097152,mode=0755)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

/dev/vx/dsk/DG/Volume on /u type vxfs (rw,delaylog,largefiles,ioerror=mwdisabl

e)

DR Site (Real Secondary

# mount -o ro -t vxfs /dev/vx/dsk/DG/Volume /mnt

UX:vxfs mount.vxfs: ERROR: V-3-21252: not super user

#

Symantec Reference to mount a Volume at Secondary Site under VVR scenerio

 https://sort.symantec.com/ecls/umi/V-3-21252

[mikebounds]

This link you provided shows you should only get this error if you try to mount rw, so maybe readonly option is not working for some reason - you could try reverse the options so use "-t vxfs -o ro", rather than "-o ro -t vxfs".

Mike

[mikebounds]

You could also try "-t vxfs -r", but this shouldn't make any difference as "-r" is the same as "-o ro".

Mike

[Zahid_Haseeb]

Let me check it and will let you know. But at my local environment (not client side where the problem occured). I ran the below command and it got successful:

# mount -o ro -t vxfs /dev/vx/dsk/DG/Volume /mnt

Client Side OS

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

My own environment OS

Red Hat Enterprise Linux Server release 5.3 (Tikanga)

So as the environment is same at both sides and my command is running fine at my environment, then it should run perfect at Client side as well :)

==================

(may be no logic on these words) The only difference is that at Client the Replication/VVR is under VCS control (means SFHA/DR or GCO) and at my environment only SF+VVR is running. Did you also do mount successful under VCS controlled VVR environment or ran in a environment where just VVR exist.

[mikebounds]

Other difference could be which mount binary is being used which will depend on path:

There are 2 mount binaries:

1. Linux one in /bin/mount
2. Veritas one in /opt/VRTS/bin (which is a sym link to /usr/lib/fs/vxfs/mount)

If both are in your path, then the one listed first will be used.

Mike

[mikebounds]

VCS should have no effect on mount commands in UNIX - it is only Windows where SFW knows if storage is under VCS control where manual SFW commands are blocked for VCS resources.

Mike

[Zahid_Haseeb]

I tried to mount Volume in my test environment (SFHA/DR) on VM with both commands you mentioned above and able to mount at DR Site with read only while I copying some files from Primary to DR Site Volume.