redefinevg和synclvodm的一个实验

转处http://blog.chinaunix.net/uid-20201831-id-4079013.html

这个实验来自于红皮书，通过这个实验可以很好的了解redefinevg和synclvodm的区别。

redefinevg和synclvodm命令

最常见的ODM问题是:ODM和LVM控制信息不同步。这种情况下，一般是ODM中的信息不准确(但不一定所有的问题都是如此)，而磁盘上的VGDA和VGSA是准确的。
修复ODM信息不准确的问题最常用的两个命令:redefinevg、synclvodm。redefinevg将重建ODM中的VG和PV信息，给出足够的信息去激活卷组，它也会恢复一些LV的信息；synclvodm将从VGDA和LVCB中恢复剩下的LV信息，以提供对LV的访问。

通过下面的例子，我们能很好的理解redefinevg和synclvodm这两个命令的区别。在下面的例子中，我们将创建名为targetvg的卷组，并在targetvg上创建targetlv文件系统，log lv为targetlog，mount点为/targetfs。

# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           jfslog     1       1       1    closed/syncd  N/A
targetlv            jfs        32      32      1    closed/syncd  /targetfs
# mount /targetfs
# echo "data" > /targetfs/data

我们假设这个VG里面的需要的所有ODM信息都损坏了，我们用odmdelete来达到破坏ODM信息的效果，在删除之前首先是备份信息(odmget备份)。
# odmdelete -o CuAt -q "name LIKE target*"
0518-307 odmdelete: 9 objects deleted.
# odmdelete -o CuDvDr -q "value3 LIKE target*"
0518-307 odmdelete: 3 objects deleted.
# odmdelete -o CuDvDr -q "value1=targetvg"
0518-307 odmdelete: 1 objects deleted.
# odmdelete -o CuDv -q "name LIKE target*"
0518-307 odmdelete: 3 objects deleted.
# odmdelete -o CuDep -q "name=targetvg"
0518-307 odmdelete: 2 objects deleted.

现在让我们来看看下面的结果。
# lsvg
rootvg
# lsvg -o
0516-304 : Unable to find device id 005f3e8e00004c000000013ac3744be1 in the Device
        Configuration Database.
vgid=005f3e8e00004c000000013ac3744be1
rootvg
# lspv -M hdisk1
0516-320 : Physical volume hdisk1 is not assigned to
        a volume group.
# lslv -m targetlv
0516-306 lslv: Unable to find  targetlv in the Device
        Configuration Database.

在ODM信息被破坏之后，我们查询不到关于VG的信息，依赖于vg的lv信息也查询不到。
即使ODM中信息是混乱的，数据依然可用，我们仍可以进行mount和umount
一些人可能会用exportvg或varyonvg来修复这个问题，我们可以尽管一试

# exportvg targetvg
0516-306 getlvodm: Unable to find volume group targetvg in the Device
        Configuration Database.
0516-772 exportvg: Unable to export volume group targetvg
# varyonvg targetvg
0516-008 varyonvg: LVM system call returned an unknown
        error code (3).
为什么exportvg没有成功呢？因为exportvg的前提是vg的定义还在，但是我们已经删除了在odm中的vg定义，
vg的定义不在，所以执行失败。

推荐的修复操作：synclvodm targetvg，也将会失败，同样是因为在odm中vg的定义已不在。
# synclvodm targetvg
0516-306 : Unable to find volume group targetvg in the Device
        Configuration Database.
0516-502 synclvodm: Unable to access volume group targetvg.

为了恢复基础的ODM信息，我们必须使用redefinevg，这里我们用redefinevg -d hdisk1 targetvg来恢复
在恢复之前，我们可以先用lqueryvg -Atp hdisk1来确认vgid信息。
# lqueryvg -Atp hdisk1
0516-320 lqueryvg: Physical volume hdisk1 is not assigned to
        a volume group.
Max LVs:        256
PP Size:        28
Free PPs:       1059
LV count:       2
PV count:       2
Total VGDAs:    3
Conc Allowed:   0
MAX PPs per PV  1016
MAX PVs:        32
Quorum (disk):  1
Quorum (dd):    1
Auto Varyon ?:  1
Conc Autovaryo  0
Varied on Conc  0
Logical:        005f3e8e00004c000000013ac3744be1.1   targetlog 1  
                005f3e8e00004c000000013ac3744be1.2   targetlv 1  
Physical:       00cb6010395938b0                2   0  
                0007c06c50569818                1   0  
Total PPs:      1092
LTG size:       128
HOT SPARE:      0
AUTO SYNC:      0
VG PERMISSION:  0
SNAPSHOT VG:    0
IS_PRIMARY VG:  0
PSNFSTPP:       4352
VARYON MODE:    ???????
VG Type:        0
Max PPs:        32512

我们可以看到，005f3e8e00004c000000013ac3744be1正好是我们用lsvg -o查出的丢失的vgid
我们运行redefinevg命令
# redefinevg -d hdisk1 targetvg
#

运行成功之后，检查信息
# lsvg
rootvg
targetvg
# lsvg -o
targetvg
rootvg
# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           ???        1       1       1    open/syncd    N/A
targetlv            ???        32      32      1    open/syncd    /targetfs
#

到此为止，我们还没有完全修复好ODM中的targetvg信息，还需要检查下当前ODM库中的信息。
# odmget CuAt |grep -ip targetvg
CuAt:
        name = "targetvg"
        attribute = "vgserial_id"
        value = "005f3e8e00004c000000013ac3744be1"
        type = "R"
        generic = "D"
        rep = "n"
        nls_index = 637

CuAt:
        name = "targetvg"
        attribute = "pv"
        value = "00cb6010395938b00000000000000000"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0

CuAt:
        name = "targetvg"
        attribute = "pv"
        value = "0007c06c505698180000000000000000"
        type = "R"
        generic = ""
        rep = "sl"
        nls_index = 0

# odmget CuDv |grep -ip targetvg
CuDv:
        name = "targetvg"
        status = 1
        chgstatus = 1
        ddins = ""
        location = ""
        parent = ""
        connwhere = ""
        PdDvLn = "logical_volume/vgsubclass/vgtype"

# odmget CuDvDr |grep -ip targetvg
CuDvDr:
        resource = "ddins"
        value1 = "targetvg"
        value2 = "42"
        value3 = ""

CuDvDr:
        resource = "devno"
        value1 = "42"
        value2 = "0"
        value3 = "targetvg"

# odmget CuDep |grep -ip targetvg

由上面的信息可以看出（也可以跟我们之前备份的信息对比），我们已经重建了odm库中targetvg的vgid，pv信息，但是我们还没有从lvcb中
恢复lv信息，这就是为什么我们在lsvg -l targetvg结果的type列中，显示为“？”的原因。在这个阶段，像extendlv等命令将执行失败，因为在
odm中没有关于targetvg的lv信息。
# extendlv targetlv 1
0516-306 getlvodm: Unable to find  targetlv in the Device
        Configuration Database.
0516-788 extendlv: Unable to extend logical volume.
#

要修复这个问题，运行synclvodm命令，这样，lvcb控制信息将会恢复到ODM中，做完这一步后，所有的ODM信息都被恢复了。
# synclvodm targetvg
# lsvg -l targetvg
targetvg:
LV NAME             TYPE       LPs     PPs     PVs  LV STATE      MOUNT POINT
targetlog           jfslog     1       1       1    open/syncd    N/A
targetlv            jfs        32      32      1    open/syncd    /targetfs
#  savebase


总结：借用农哥的原话。
synclvodm是从VGDA同步ODM，前提是VG的定义还在，ODM里错误的被修正，缺失的会从VGDA导入，但ODM里多的还会存在。
redefinevg也是从VGDA同步ODM，前提是VG定义没了才用，要指定从哪个PV导入，ODM里多的还会在
synclvodm同步vgda和lvcb中的信息到odm
redefinevg总是能执行成功的，因为pv信息如果在odm中被删除了，还可以通过cfgmgr来认出来
exportvg是把VGDA信息从ODM库中导出去，前提也是VG的定义还在。