Cloning and using SG vg

[Ray Allen_1]

Hi All,

I am trying to figure if it is possible, or a way around cloning a SG production vg, which contains the production database, from the primary node, and presenting the cloned(Using Continous Access on the EVA)luns to the alternate node, and bring up the database using the different vgname on the alternate node.
We would like to be able to create other databases from the cloned production database and refresh other databases on the alternate node. What we have done so far, was to create the map file (using the -p -v -s -m options) of the production database, and imported the vg.
When we try to activate the vg, we are getting the error "vg conflicts with configured mode". I know this is related to SG, but I'm just trying to figure out it this is possible, or if there is away around what we are trying to accomplish.

Thanks

[Siju Vadakkan]

What I understood is u already created CA and Split it and imported the volume group successfully but not able not activate the VG. What you can do is, remove the cluster aware and activate it.

#vgchange -c n
#vgchange -a y

[Rita C Workman]

Most anything is possible. Here's a couple things to consider.

If both nodes are within the cluster, that may create issues for you down the line. If you want to split off a mirror (cloned) copy, then mount up on a server outside your clustered environment you will have less issues.
But if you are within the cluster than one thing you might need to do is change the vgid on the cloned vg using vgchgid. Again I don't recommend doing this if both nodes are within the cluster.

Just a thought,
Regards,
Rita

[Stephen Doud]

The vgimport you mentioned will only import the same (primary data set) LUNs on the alternate node. That's usually necessary when you intend to run the SG package on the alternate node.

However, since you seem to want a static clone of the data, and since CA is involved, you could pairsplit the mirror copy off of the main copy, then use 'vgchgid' on the ALL of the mirror set of disks and then import the mirror set under a different VG name.
I believe the vgchgid strips off the cluster-aware bits in the VG metadata on-disk.
When you get a message from vgchange that includes "activation mode conflicts with configured mode", it means that you are using
# vgchange -a y
when the LVM metadata on-disk indicates it should be activated with
# vgchange -a e

The opposite is also true (use -a y instead of -a e).

You could then mount the new VGs' file systems to copy the static data or even do a dd of the logical volume to another of the exact same size, if this is a raw database.

[Ray Allen_1]

Rita
Yes. I want to mount everthing outside the cluster.

Stephen.
I found this forum http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1144581
that explains exactly how to do what I needed. Which explains what you mention about stripping vgid with vgchgid. I imported the vg's with different names.
eg. vgfrsh_orcl1 and vgfrsh_orcl2
However, after importing and activiting the vg's, I am not sure if it safe to mount the filesystems using the same production lvol names that carry over from the production vg mapfiles. I tried renaming the lvols under the imported vgname on the alternate and mounting the filesystems, but it failed with "cannot deduce character device name"
Once I rename the lvols back to their original names,and tried mounting the filesystems to a temporary mount point, it fails with filesystem corrupt,which I know I can fix with fsck.
If I mount the filesystems usgin the production lvol names, will this interfere with failover if the primary node fails over to the alternate node?

[Stephen Doud · Accepted solution]

For the error, "cannot deduce character device name", check the minor number on the raw special file vs. block special file for each logical volume - they are likely different. They should be paired such as:
block special file:
brw-r--r-- 1 root sys 64 0x000001 Jul 27 2007 lvol1

and
raw special file:
crw-r----- 1 root sys 64 0x000001 Apr 3 2004 rlvol1

Note the minor numbers are the same (0x000001) - and the first part of it should match the 'group' file minor number, ie: 0x000000
--

You can create a map file with custom names. Eg: vgfrsh_orcl2.map
1 lvdata1
2 lvdata2
And use this map file to import the CA/vgchgid'd VG.. eg:
# vgimport -m vgfrsh_orcl2.map /dev/vgfrsh_orcl2.map /dev/dsk/c_t_d_ ... (use the right dsk device file)

I am not sure whether it is legal to simply rename the device special files for the logical volumes.

As for the safety of mounting the CA-mirror set to the same mount points as the failover package - the answer is, "depends"... if a failover occurs, then NO, because a file system will not mount over another file system.
Example:
# mount /dev/vgSG/lvol1 /opt
UX:vxfs mount: ERROR: V-3-21264: /dev/vgSG/lvol1 is already mounted, /opt is busy,
allowable number of mount points exceeded

[Ray Allen_1]

Stephen. Dude. You are AWESOME!!!!! If I could give you 100 points, I would.

I modified the vg mapfile, changed the name of the listed lvols. Imported the vg's and mounted the filesystems successfully with the new lvol names. Had to fsck the filesystems, but thats okay.
Worked perfectly.


ITRC Rocks!!!

Thanks everyone for all your help.

[Ray Allen_1]

With the help of everyone and itrc forum. The question was resolved usign the following steps.



1. Create the directories for the TARGET VGs.
mkdir /dev/vgXX

2. Create the group files for each VG
mknod /dev/vgXX/group c 64 0x??0000

(Note that the minor number should be unique on that target server and check the maxvgs kernel parameter to check upto how many VGs you can create - if this value is not allowing you to have all the required no. of VGs , then you will have to increase this parameter and rebuild kernel)

3. Change the VGID of the target LUNs.
e.g. if say c21t0d0, c21t0d1 and c21t0d2 are the TARGET LUNS (from autopath display) for vgXX, then

vgchgid /dev/rdsk/c21t0d0 /dev/rdsk/c21t0d1 /dev/rdsk/c21t0d2


4. Create map file from SOURCE VG without actually exporting it.
e.g. vgexport -p -m vg01.map

(Note that -s is not used as it records the VGID and you would be changing the VGID in step 4)
(Note: If using cloned luns in a Service Guard environment, you must modify the new vg map file, and change the name of listed lvols before importing the vg to the new lun device file.

5. Import the target VG (SVOLS)

vgimport -v -m vg01.map /dev/vg01.ca /dev/dsk/c21t0d0 /dev/dsk/c21t0d1 /dev/dsk/c21t0d2


6. Activate the VGs
vgchange -a y /dv/vg01.ca


7. Extend VG to use alternate path {if there is alternate path]

vgextend /dev/vg01.ca /dev/dsk/c41t0d0 /dev/dsk/c41t0d1 /dev/dsk/c41t0d2
(Assuming c41t0d0 is alternate path for c21t0d0)

8. Mount the filesystems to the mount points
If you get a filesystem needs checking, run fsck to hopefully clean the filesystem.
fsck –F vxfs –y /dev/vgXX/lvolxxx

Done