无法激活由心脏起搏器管理的逻辑卷

Question

我有两台CentOS 7服务器，它们以主动/被动的方式进行工作。整个想法是在活动节点出现问题时移动挂载点。我的客户想做安全加固，然后他们重新启动服务器。重新启动后，我无法再次启动集群。

因此，我销毁了集群，并希望重新配置。但由于某些原因，文件系统资源无法启动。当我们检查日志时，我们看到了fusvg that is some volume group does not close correctly错误。

我想这应该是lvm分区的一个问题。逻辑卷显示不活动。我尝试了lvchange -a y fusvg命令来激活它，但是没有工作。

如/dev/fusvg/fuslv输出所示，我的逻辑卷设备文件不在lvdisplay中。

以下是lvdisplay输出：

[root@machine-name ~]# lvdisplay 
  --- Logical volume ---
  LV Path                /dev/fusvg/fuslv
  LV Name                fuslv
  VG Name                fusvg
  LV UUID                rL2svQ-kxnJ-GdD8-2aKX-Omcv-eywn-Q5rtRG
  LV Write Access        read/write
  LV Creation host, time machine-name, 2018-06-22 13:34:13 +0300
  LV Status              NOT available
  LV Size                <30.00 TiB
  Current LE             7864318
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

以下是vgdisplay输出：

[root@machine name ~]# vgdisplay 
  --- Volume group ---
  VG Name               fusvg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  21
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <30.00 TiB
  PE Size               4.00 MiB
  Total PE              7864318
  Alloc PE / Size       7864318 / <30.00 TiB
  Free  PE / Size       0 / 0   
  VG UUID               CMG3yi-qHSO-3qMP-CF1h-nG9Y-Uh34-KlWwiI

以下是lsblk输出：

NAME                                    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                       8:0    0 446.6G  0 disk  
├─sda1                                    8:1    0     1G  0 part  /boot
├─sda2                                    8:2    0 317.6G  0 part  /
└─sda3                                    8:3    0   128G  0 part  [SWAP]
sdb                                       8:16   0    30T  0 disk  
└─36000d31003f63c000000000000000003     253:1    0    30T  0 mpath 
  └─36000d31003f63c000000000000000003p1 253:3    0    30T  0 part  
sdc                                       8:32   0     5G  0 disk  
└─36000d31003f63c000000000000000004     253:0    0     5G  0 mpath 
sdd                                       8:48   0    30T  0 disk  
└─36000d31003f63c000000000000000003     253:1    0    30T  0 mpath 
  └─36000d31003f63c000000000000000003p1 253:3    0    30T  0 part  
sde                                       8:64   0     5G  0 disk  
└─36000d31003f63c000000000000000004     253:0    0     5G  0 mpath 
sdf                                       8:80   0    30T  0 disk  
└─36000d31003f63c000000000000000003     253:1    0    30T  0 mpath 
  └─36000d31003f63c000000000000000003p1 253:3    0    30T  0 part  
sdg                                       8:96   0     5G  0 disk  
└─36000d31003f63c000000000000000004     253:0    0     5G  0 mpath 
sdh                                       8:112  0    30T  0 disk  
└─36000d31003f63c000000000000000003     253:1    0    30T  0 mpath 
  └─36000d31003f63c000000000000000003p1 253:3    0    30T  0 part  
sdi                                       8:128  0     5G  0 disk  
└─36000d31003f63c000000000000000004     253:0    0     5G  0 mpath  

Answer 1

今天在戴尔HA上遇到了这个问题。不确定这是特定于它们的实现，还是标准无处不在，但SuSE的KB“尝试激活共享LVM卷组时获取错误”导致我将共享卷组添加到/etc/lvm/lvm.conf中的volume_list设置中。一旦完成，我就可以执行一个lvchange并开始挂载共享文件系统。