VGDA out of sync
With HACMP, you can run into the following error during a verification/synchronization:
WARNING: The LVM time stamp for shared volume group: testvg is inconsistent with the time stamp in the VGDA for the following nodes: host01
To correct the above condition, run verification & synchronization with "Automatically correct errors found during verification?" set to either 'Yes' or 'Interactive'. The cluster must be down for the corrective action to run.
This can happen when you've added additional space to a logical volume/file system from the command line instead of using the
smitty hacmp menu's. But you certainly don't want to take down the entire HACMP cluster to solve this message.
First of all, you don't. The cluster will fail-over nicely anyway, without these VGDA's being in sync. But, still, it is an annoying warning, that you would like to get rid off.
Have a look at your shared logical volumes. By using the
lsattr command, you can see if they are actually in sync or not: host01 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:809:jfs2:y:
host02 # lsattr -Z: -l testlv -a label -a copies -a size -a type -a strictness -Fvalue
/test:1:806:jfs2:y:
Well, there you have it. One host reports testlv having a size of 806 LPs, the other says it's 809. Not good. You will run into this when you've used the extendlv and chfs commands to increase the size of a shared file system. You should have used the smitty menu's.
The good thing is, HACMP will sync the VGDA's if you do some kind of logical volume operation through the
smitty hacmp menu's. So, either increase the size of a shared logical volume through the smitty menu's with just one LP (and of course, also increase the size of the corresponding file system); Or, you can create an additional shared logical volume through smitty of just one LP, and then remove it again afterwards.
When you've done that, simply re-run the verification/synchronization, and you'll notice that the warning message is gone. Make sure you run the
lsattr command again on your shared logical volumes on all the nodes in your cluster to confirm.
Hacmp / High Availability - Meilink.net
HACMP Synchronization problem
choice1: leave it to lazy update to fix when hacmp falls over next time, or fix when you have a maintenance window.
choice2: Do change in FS
temporary unlock VG on node that owns VG at the moment:varyonvg -b -u VGNAME
On node that does NOT have VG active run importvg -L VGNAME hdiskNAME
On node that HAS VG active, LOCK VG again: varyonvg VGNAME
