UNCLASSIFIED Hi Joel,
I am unsure as to why vxrecover has wedged itself like this. It does look like it is trying to abort it's current task and cannont for some reason. I would err on the side of caution and leave it until the next maintenance window and reboot the box. However, Veritas support may know better. What you should do now is recover those volumes in the NEEDSYNC state. Eg.: v mysqlData01-L01 fsgen ENABLED 13107200 - NEEDSYNC - - pl mysqlData01-P01 mysqlData01-L01 ENABLED 13107200 - ACTIVE - - sd silo2dg01-05 mysqlData01-P01 ENABLED 13107200 0 - - - pl mysqlData01-P02 mysqlData01-L01 ENABLED 13107200 - ACTIVE - - sd silo2dg09-05 mysqlData01-P02 ENABLED 13107200 0 - - - Something like: # vxrecover -b mysqlData01-L01 And then wait for it to finish re-syncing the mirror. Repeat for the rest of the volumes in that same state. You don't want to do more than 1 or 2 vxrecovers at once, all the I/O may bring the box to it's knees. I've done that before :-) Greg. -----Original Message----- From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of joel Sent: Tuesday, 21 July 2009 2:38 PM To: Robinson, Greg Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] vxdisk path question/concern [SEC=UNCLASSIFIED] Nice I appreciate all your help with this. I am understanding the ins and outs a much better. I removed the disk silo2gd17 without a problem. One last thing is this task that's running. It was started by another operator a few days ago and now it just seems to be stuck: [r...@p02cd01 ~]# vxtask -l -h list Task: 162 ABORTING Type: PARENT Operation: VXRECOVER Started: Fri 17 Jul 2009 12:41:56 AM PDT Progress: 13.56% (8 of 59 jobs, 2 active) root 4489 0.0 0.0 4732 1712 ? Ss Jul17 0:00 vxrecover -g silo2dg -sb This was done I am assuming because of the bad state the system was in at the time. Any ideas on that one? I don't want to kill off the job if it's going to have repercussions. Thanks again ~joel Robinson, Greg wrote: > UNCLASSIFIED > > Hi Joel, > > Well, everything is looking good. I'd run vxdiskadm again and chose > option 3, to remove that disk, silo2dg17. > > Any volumes in the NEEDSYNC state will recover by themselves. Any > others, will need a manual recover. Something like: > > # vxrecover -b mysqlData07-L05 > > For example. > > Greg. > > -----Original Message----- > From: joel [mailto:j...@saldino.net] > Sent: Tuesday, 21 July 2009 11:10 AM > To: Robinson, Greg > Cc: veritas-vx@mailman.eng.auburn.edu > Subject: Re: [Veritas-vx] vxdisk path question/concern > [SEC=UNCLASSIFIED] > > I was able to add sdf back in as the replacement and it seems to be > recovering now. Here is the output you asked for, it's alot. > silo2dg17 > > was my mistake when I added it back in I just picked the default name > which went to the next number up. I removed that and re-added as > silo2dg05 and it seemed to have worked fine. > > [r...@p02cd01 ~]# vxprint > Disk group: silo2dg > > TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 > > PUTIL0 > dg silo2dg silo2dg - - - - - > - > > dm silo2dg01 sda - 143366528 - NOHOTUSE - > - > dm silo2dg02 sdb - 143366528 - NOHOTUSE - > - > dm silo2dg03 sdc - 143366528 - NOHOTUSE - > - > dm silo2dg04 sdd - 143366528 - NOHOTUSE - > - > dm silo2dg05 sdf - 143366528 - NOHOTUSE - > - > dm silo2dg06 sde - 143366528 - NOHOTUSE - > - > dm silo2dg07 sdg - 143366528 - NOHOTUSE - > - > dm silo2dg08 sdh - 143366528 - NOHOTUSE - > - > dm silo2dg09 sdi - 143366528 - NOHOTUSE - > - > dm silo2dg10 sdj - 143366528 - NOHOTUSE - > - > dm silo2dg11 sdk - 143366528 - NOHOTUSE - > - > dm silo2dg12 sdl - 143366528 - NOHOTUSE - > - > dm silo2dg13 sdm - 143366528 - NOHOTUSE - > - > dm silo2dg14 sdn - 143366528 - NOHOTUSE - > - > dm silo2dg15 sdo - 143366528 - NOHOTUSE - > - > dm silo2dg16 sdp - 143366528 - NOHOTUSE - > - > dm silo2dg17 - - - - REMOVED - > - > > [.. Snip ..] > > IMPORTANT: This email remains the property of the Australian Defence > Organisation and is subject to the jurisdiction of section 70 of the > Crimes Act 1914. If you have received this email in error, you are > requested to contact the sender and delete the email. > _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx