Service guard failover and Business copy

[Paul Willder]

I have a 2 node cluster consiting of 2 RP4440's and using HP-UX 11.23 and SG .17
attached to an XP 10K
the primary server runs an oracle database
the secondary server runs a business copy version of the production database as well as a static copy of the same database (2 Business copies)

following a failed CPU the failover was initialized and fail over worked great, the active business copy database was shutdown on the secondary node and the production database switch over to the secondary node.

later in the day I switch the cluster back, with no issues, I then remounted the Business copy volume groups and mounted the directories.

the next day following the split and join of the disks, the file systems were unable to mount.

normally the process (which has been running for months) does the following:

umount of /ora1
vgchange -a n BC_VG

(normal join and split of disks)

vgchgid /dev/rdsk/c5t0d1 /dev/rdsk/c17t0d1 ..
vgimport /dev/BC_VG /dev/dsk/c5t0d1 /dev/dsk/..
fsck /dev/BC_VG/lvol1
mount -F vxfs -o rw /dev/BC_VG/lvol1 /ora1

The disk were unable to mount as it appeared they were in use. I had to manually do the following to get the disks to mount.

vgexport /dev/BC_VG
mkdir /dev/BC_VG
mknod /dev/BC_VG/group c 64 0x200000

vgchgid /dev/rdsk/c5t0d1 /dev/rdsk/c17t0d1 ..
vgimport /dev/BC_VG /dev/dsk/c5t0d1 /dev/dsk/..
fsck /dev/BC_VG/lvol1
mount -F vxfs -o rw /dev/BC_VG/lvol1 /ora1



has anyone any idea why I had to do a vgexport on the Volume Groups and recreate them??

Thanks

Paul

[Armin Kunaschik]

I suspect, that the /etc/lvmtab was out of date (in terms of BC_VG).
Did you create another BC on node2? That would change the VG id and the lvmtab on node1 will be invalid.
Remember: You always change the VG id to a random new one with vgchgid.
You should alway export the BC_VG before you create a new copy.. and export the VG on all currently inactive nodes!

My 2 cents,
Armin

[Geoff Wild]

I don't know the answer to your issue, but I have a comment on your design.

I would never mount Business Copies (or clones in the EMC world) on a node in a cluster that also has access to the standards.

You really should have another host (separate from the cluster) to mount your Business copies. It is way to easy to make a mistake on a vgimport and/or vgchgid that could impact production.

A cluster provides High Availability - and that's what it should be used for.

My 2 cents.

Rgds...Geoff

[David Bellamy]

Paul vgexport and recreation of the BC volume groups are standard practice in our organization. We don't use vgchid because we mount the BC_VG on another host that do not have access to the primary vg.

[skt_skt]

"The disk were unable to mount as it appeared they were in use"

In following set of commands you used for first try to mount, do you remember at what step/what error did u get exactly?

it looks like you tried exporting and it worked later.I can guess due to the urgency your intention is bring it up ASAP.

You may get diiferent openion/scenarios now.But that may not be exactly your case