线上业务LVM磁盘故障更换 unknown device故障

处理流程

服务器的磁盘采用了lvm方案进行多盘组合，但是在海量文件的高并发读取下，尽管是ssd硬盘也经不起摧残，最近发现有部分文件无法访问，进入服务器才发现lvm有一块硬盘报unknown device，挂载错误。

警告

不要尝试重启，这是血的教训，重启后远程服务器都不知道进入啥模式了，会导致在线运行的业务直接迭掉。恰好机房的vnc也出了故障无法使用，简直抓瞎，幸好遇到和蔼可亲的机房维护人员帮助检查并且更换了硬盘
静等换上新的新盘就好，实际上换上新的硬盘，然后把数据在备份差异化同步过来就好。

如果手贱进行了不该的操作

如果你到网络上不小心搜索了以下，如同我一样，就会产生无所谓的悲剧，我特意将所有的悲剧记录下来，便于参考

vgreduce --removemissing VG --force

大部分急病乱投医可能执行到这个，刚开始可能会报错，大致的意思就是文件系统在运行中，但是你可以先取消挂载后执意坚持执行。
这样会导致数据表面丢失的错误。

vgcfgrestore -f xxxxxx.vg VG

数据丢失是不是要恢复，所以我做了一件事，通过vgcfgrestore --list vg命令获取到最后一次配置备份，然后修改了备份配置文件（先备份），将unkown的硬盘删除，然后执行坚持执行，恭喜，表面恢复正常，但是实际上无法挂载，会报块错误，大意就是逻辑卷的块大于物理卷的块，无法挂载。

resize2fs /dev/VG/LV

如果你把报错放入搜索引擎的搜索框，大致会建议你使用这个命令，实际上你会陷入长长的按y的结局中，我按了十几分钟的y键之后，觉得这特么扯淡了，所以最终没有一直按下去。

机房换了硬盘后

执行blkid发现uuid没有变更，灵光一闪，这不是可以把刚才备份的配置备份再执行一次vgcfgrestore -f xxxxxx进行恢复吗。

再次还原配置

1. vi /etc/lvm/archive/***.vg
2. 将device为unkown修改成/dev/xxx
3. 将flags里面的missing状态去掉
4. 保存，退出:wq+Enter
5. 移除逻辑卷（如果你执行vgcfgrestore修复过错误）lvremove VG LV
6. 再次恢复配置vgcfgrestore -f /etc/lvm/archive/xxxxxx.vg VG
7. 激活lvchange -ay /dev/VG/LV

分区错误恢复

按照提示执行修复：e2fsck /dev/VG/LV，现在按y手不疼了，按了1分钟就结束了，然后发现可以挂载了。
mount /dev/VG/LV /home

添加自动挂载

修改/etc/fstab文件，末尾添加

/dev/VG/LV /home ext4 noatime,defaults 0 0