Mirror and Strip problem!

[Fragon]

L2000/HP-UX11.00(64bit)
Disk1 18G(10K)
Disk2 18G(10K)

Disk1 & Disk2 both belong to vg00 and all Logical Volumes (include DB and application LV) have strict mirror! Normally the primary boot disk is Disk1. One day when I rebooted the system, I found that Disk1 boot fail, Disk1 is bad. So I boot from Disk2, it is OK! Users update daily data as usual on Disk2. (This time no mirror, of course) But nextday when I reboot the system, Disk1 became usable again.
I boot from Disk2 again and no problem. When booted, the system start to synchronize vg00. I just want to know whether Disk1 flood data to Disk2 or Disk2 flood data to Disk1? Or new data cover old data anyway?
Resource links or docs are all appreciated and thankful!!!

Another case please!
I want to add 2 more disks Disk3 & Disk4 also 18G(10K). I want make Disk1&Disk3 strip (S0), Disk2&Disk4 strip(S1), and S0/S1 make a mirror. I have Mirror/UX installed. I know strip function include in LVM(lvcreate & lvextend)in HP-UX. Would these resource(Hareware & Software) be OK ? I make a plan on how to achieve this, but more advice is necessary and very appreciated!

Thank in advance!

-ux

[Rajeev Shukla · Accepted solution]

Hi,

The mirror syncronisations works on primary and seconday mirror. So if you have a look on LV by doing lvdisplay you'll see the first disk is the primary and second disk is seconday. So the mirror syncronisation will happen from primary to seconday disk and that is true for all LV's in the mirror.

2nd case.
Yes with just Mirror-UX and enough disk you can do stiping and mirroring my using lvextend in a loop with a counter and create sripes on both the disk and finally mirror that to another.
But you know you'll have better performance if you go for Veritas Volume manager in this case. Coz this type of scenario works best with VXVM.

Rajeev

[Con O'Kelly]

Hi

Well lets hope its syncs disk2 to disk1, otherwise I assume you'll lose data.
I have to say I'm not 100% sure but my understanding is that it uses the stale extents to know which way to sync. So on disk1 as a result of the bad disk you have all stale extents. LVM/Mirror/UX keeps track of those stale extents. Once the disk is OK again it will sync from the "good" extents to the stale extents. So I'd assume that when disk1 comes back up, LVM knows that all the stale extents reside on that disk & hence will sync from disk2.
Hope that makes sense!!
I'd be interested to see hear what others think.

The HP-UX Software Recdovery handbook has a good chapter on LVM.
http://www2.itrc.hp.com/service/iv/node.do?node=prod%2FWW_Start%2FN1%7C16

Cheers
Con

[Steven E. Protter]

Okay,

Disk1 is going to go again, which is much more serious than anything I've seen in this thread so far.

The best way to get your system back to the way it was before the failure is thus:

1) Get your latest Ignite make_tape_recovery tape
2) Arrange replacement of disk1, and get the controller, cables and drive cage checked.

Boot the system of off make_tape_recovery tape.

Boot the box at the console

Interupt at the 10 second prompt

sea

The tape is the sequential device

bo p##

replace ## with the nubmer of the boot device.

N Do not interact with the ISL

In three hours you get your system back.

I have seen some confusing lvm setups, but I try to keep things simple. I use mirroring and not striping. If disk space is tight, I'll mirror boot and stripe the rest of the machine.

I think your setup could be simplified after you recover your system.

I think in your original scenario the system changes and logs made while running on disk 2 are gone.

SEP

[twang]

Case 1, I would like to verify that the BDRA information is accurate:
# lvlnboot -v

Case 2,
I had carried similar actions on our oracle application, but the performance is not good.

[Fragon]

Hi, thank you all!
I boot from Disk2 and did not make a reboot at all, the lvlnboot info like this:
#lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t2d0 (0/0/1/1.2.0) -- Boot Disk
/dev/dsk/c2t2d0 (0/0/2/0.2.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Root: lvol3 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Swap: lvol2 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Dump: lvol2 on: /dev/dsk/c1t2d0, 0

But, from the answers I still unsure how the data synchronize for this case!

Only 2 disks for strip I also think it will get so little up for performance! But I must make a try!

Many thanks for all!

-ux

[Fragon]

Hi, thank you all!
I boot from Disk2 and did not make a reboot at all, the lvlnboot info like this:
#lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t2d0 (0/0/1/1.2.0) -- Boot Disk
/dev/dsk/c2t2d0 (0/0/2/0.2.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Root: lvol3 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Swap: lvol2 on: /dev/dsk/c1t2d0
/dev/dsk/c2t2d0
Dump: lvol2 on: /dev/dsk/c1t2d0, 0

But, from the answers I still unsure how the data synchronize for this case!

Only 2 disks for strip I also think it will get so little up for performance! But I must make a try!

Many thanks for all!

-ux

[Fragon]

I read the LVM manual and only get this info. , but I more agree it:
========================
Based on timestamps on the disks LVM decides which is the good copy and which is the bad
one so you do not have to specify devicefiles here.
========================
Above is the mirror LVs synchronization! I think VGs will be the same.

Any other ideas?

[Con O'Kelly]

Hi (again)

The honest answer is I'm really not sure, though its a good question.

Normally if your boot disk fails (& is mirrored!) you replace it & then go through the normal commands:
vgcfgrestore, vgchange, mkboot, lvlnboot etc.

If I understand you correctly, your situation is that the primary boot disk failed, you booted off alternate disk (with system now only updating to the alternate disk) & then the next day when you rebooted the primary disk was OK again??

I'd still think that LVM would have the smarts to figure which extents were stale before & update them from the alternate disk.

Can you check what files were updated on the day primary disk was offline & see if they have the correct data now.
For example if you added a user, then the passwd file was updated & that user should still be in the passwd file. If it only synced from the primary disk then it would have replaced the newer passwd file with the older one.

Check for any stale extents with:
# vgdisplay -v vg00 | grep stale.

Either way, I'd concur with SEP and get the disk replaced.

Cheers
Con

[Fragon]

I can remember one thing!
When the Disk1 is fail and I boot the system from Disk2, I have change a kernel parameter "dbc_max_pct" from 50 to 10. And when Disk1 is OK and I boot the system from Disk2, after synchronizing vg00, I found the dbc_max_pct is 10 also. This the fact!
So I can make sure that data is not always flood from primary disk to secondary disk.
But I still can't make sure if data flood from booting-disk to another disk or flood by timestamps of the files.


mmmmm.....