Video Screencast Help
Search Video Help Close Back
to help

Unable to failover service group in 2 node cluster, for error V-16-10001-5506

Created: 06 Feb 2013 | Updated: 07 Mar 2013 | 3 comments
Vivek Shamraj's picture
Vivek Shamraj
0 0 Votes
Login to vote
This issue has been solved. See solution.

Hi All

 

I was trying to failover my sybase group, on to the secondary node and it fails for following reasons :

 

2013/02/06 10:58:34 VCS INFO V-16-1-10298 Resource sybasedg (Owner: Unspecified, Group: Sybase1) is online on node2 (VCS initiated)
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 ()node2 Mount:sybmaster_mount:online:BlockDevice </dev/vx/dsk/sybasedg/sybmaster> does not exist. Resource <sybmaster_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:syblog_mount:online:BlockDevice </dev/vx/dsk/sybasedg/syblog> does not exist. Resource <syblog_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:sybdata_mount:online:BlockDevice </dev/vx/dsk/sybasedg/sybdata> does not exist. Resource <sybdata_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:pmsyblog_mount:online:BlockDevice </dev/vx/dsk/sybasedg/pmsyblog> does not exist. Resource <pmsyblog_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:pmsybdata_mount:online:BlockDevice </dev/vx/dsk/sybasedg/pmsybdata> does not exist. Resource <pmsybdata_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:fmsyblog_mount:online:BlockDevice </dev/vx/dsk/sybasedg/fmsyblog> does not exist. Resource <fmsyblog_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:fmsybdata_mount:online:BlockDevice </dev/vx/dsk/sybasedg/fmsybdata> does not exist. Resource <fmsybdata_mount> will not go online
2013/02/06 10:58:35 VCS WARNING V-16-10001-5506 (node2) Mount:dbdumps_mount:online:BlockDevice </dev/vx/dsk/sybasedg/dbdumps> does not exist. Resource <dbdumps_mount> will not go online

 

Is there standard recovery mehod for this ?

 

Regards

Vivek

Discussion Filed Under:
,

Comments 3 Comments • Jump to latest comment

mikebounds's picture
mikebounds Trusted Advisor
Unable to failover service group in 2 node cluster, for error V-16-10001-5506 - Comment:06 Feb 2013 : Link

The diskgroup agent normally recovers and start the volumes so it looks as though this didn't work for some reason.  You could try manually:

vxrecover -sg sybasedg

After you have ran this, see if volume device files exist in /dev/vx/dsk/sybasedg.  If it doesn't work, please provide output of "vxprint -thg sybasedg"

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has helped you, please vote or mark as solution

0
Login to vote
  • Actions
Vivek Shamraj's picture
Vivek Shamraj
Unable to failover service group in 2 node cluster, for error V-16-10001-5506 - Comment:06 Feb 2013 : Link

Hello Mike

Unfortunately due to deadline, i had to do a re-install of my product, wont be able to provide any clue on this now.....but if you have any referal material to go through , can you please let me know ?

Vivek

0
Login to vote
  • Actions
mikebounds's picture
mikebounds Trusted Advisor
Unable to failover service group in 2 node cluster, for error V-16-10001-5506 - Comment:07 Feb 2013 : Link

If you look in the VCS Bundled Agent guide for the platform and version you are using the Diskgroup agent will have a definition like the following for StartVolumes attributes

 

StartVolumes
If value of this attribute is 1, the DiskGroup online
function starts all volumes belonging to that disk group
after importing the group.
Note: With VxVM version 5.1.100.0 onwards, if the Veritas
Volume Manager default autostartvolumes at system level
is set to on, all the volumes of the disk group will be
started as a part of the import disk group.
Type and dimension: boolean-scalar
Default: 1
 

So unless you changed the default from 1 to 0, then your volumes should have been started, so the possibilties that could have occured are:

  1. StartVolumes was set to 0
  2. There was a mistake in the blockdevice, so for example, the sybasedg resource could be managing a diskgroup called "sybase-dg" and this would make your blockdevice wrong
  3. The volumes failed to start when the diskgroup agent tried to start them

Mike

UK Symantec Consultant in VCS, GCO, SF, VVR, VxAT on Solaris, AIX, HP-ux, Linux & Windows

If this post has helped you, please vote or mark as solution

SOLUTION
0
Login to vote
  • Actions