一、问题描述
因某次MySQL binlog占用过高扩容时，是直接对云盘操作，而扩容直接操作了lvm卷而未操作云盘分区，并随后执行了扩容的partprobe，resize2fs卷等操作；最后，显示并未扩容成功，重启系统后，无法进入，包文件系统错误，无法加载，注释后重启，发现LVM信息丢失。
参考：recover-lvm2-partition、serverfault
二、过程复现及修复
2.1、过程复现
fdisk /dev/mapper/mysql_data-mysql #执行了d分区操作，主从应该在云盘分区操作
e2fsck -f /dev/mapper/mysql_data-mysql
fuser -m -v -i -k /opt/mysql
umount /dev/mapper/mysql_data-mysql /opt/mysql
resize2fs /dev/mapper/mysql_data-mysql
重启后报错如下：
注释故障盘后，重启进入系统，执行pvs vgs lvs 发现无之前的相应的PV,VG,LV 信息，至此，lvm信息丢失。因此，必须考虑恢复lvm信息才能进一步恢复数据；实际LVM的元数据信息是会在lvm变动那一刻自动备份的，目录保存在/etc/lvm/目录下，vg在archive目录下，lv在backup下；即LVM 会默认存储用户对 PV/VG/LV 的每一步操作，并自动把当前的 VG 的信息备份到一个文件里面，位置是 /etc/lvm/backup/VG 名或者 /etc/lvm/archive/VG 名。这个文件里面记录的东西大概跟 vgdisplay/pvdisplay/lvdisplay 输出的信息一致，里面也包括了对于恢复 VG 信息至关重要的 PV UUID。综上，我们可以利用这些备份进行进行LVM恢复。
回顾：super block 是硬盘分区开头——开头的第一个byte是byte 0，从 byte 1024开始往后的一部分数据。由于 block size最小是 1024 bytes，所以super block可能是在block 1中（此时block 的大小正好是 1024 bytes），也可能是在block 0中。 超级块中的数据其实就是文件卷的控制信息部分，也可以说它是卷资源表，有关文件卷的大部分信息都保存在这里。例如：硬盘分区中每个block的大小、硬盘分区上一共有多少个block group、以及每个block group中有多少个inode。
2.2、LVM及文件系统修复
#列出在Linux中恢复LVM元数据的备份文件
vgcfgrestore --list mysql_data #输出如下File: /etc/lvm/archive/mysql_data_00000-369742915.vgCouldn't find device with uuid gzdJP8-ltvz-l2Kd-WfJD-335J-NrDd-mhwi7w.VG name: mysql_dataDescription: Created *before* executing 'vgcreate mysql_data /dev/sdb1'Backup Time: Thu Jun 16 15:17:40 2022File: /etc/lvm/archive/mysql_data_00001-1831552697.vgVG name: mysql_dataDescription: Created *before* executing 'lvcreate -n mysql -l 100%VG mysql_data'Backup Time: Thu Jun 16 15:19:52 2022File: /etc/lvm/backup/mysql_dataVG name: mysql_dataDescription: Created *after* executing 'vgs'Backup Time: Mon Oct 2 21:46:48 2023#查看重启后的sdb1磁盘的UUID，原来的是sdd盘号，对应sdd1，重启后变成了sdb1
pvdisplay /dev/sdb1--- Physical volume ---PV Name /dev/sdb1VG Name mysql_dataPV Size <1024.00 GiB / not usable <3.97 MiBAllocatable yes (but full)PE Size 4.00 MiBTotal PE 262143Free PE 0Allocated PE 262143PV UUID gzdJP8-ltvz-l2Kd-WfJD-335J-NrDd-mhwi7w #这里是更正后，原来的没截图；正常如果这里的ID与原来的不一样，也会导致vg无法识别，从而无法正常加载lvm信息#备份
dd if=/dev/sdb1 of=/data/sdb1.img
#备份MBR分区表
dd if=/dev/sda of=/path/to/backup bs=512 count=1 skip=1
#恢复分区表，然后输入“x”进入高级模式，在其中选择“e”来编辑分区表，并将备份数据写入主分区表
fdisk /dev/sda#查看lvm备份信息获取原UUID
less /etc/lvm/backup/mysql_data#使用原来的 PV UUID 来创建 PV，并使用自动备份的文件来恢复信息。pvcreate /dev/sdb1 -u gzdJP8-ltvz-l2Kd-WfJD-335J-NrDd-mhwi7w --restorefile /etc/lvm/backup/mysql_data -vv #加--test 参数测试命令执行后再执行，-u=--uuid，-ff参数强制重做pvdisplay /dev/sdb1 #严重#恢复 VG
vgcfgrestore -f -v /etc/lvm/backup/mysql_data mysql_data #也可以用--test#验证
vgs
vgscan
vgchange -ay mysql_data #激活vg分区lvs #验证显示正常mount /dev/mysql_data/mysql /opt/mysql #报错，无法挂载#检查文件系统
tune2fs -l /dev/mysql_data/mysql #报错tune2fs 1.42.9 (28-Dec-2013)
tune2fs: Bad magic number in super-block while trying to open /dev/mysql_data/mysql
Couldn't find valid filesystem superblock.#检查超级快
dumpe2fs /dev/mysql_data/mysql | grep superblockdumpe2fs 1.42.9 (28-Dec-2013)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mysql_data/mysql
Couldn't find valid filesystem superblock.#找不到超级快，使用以下命令查找
mke2fs -n /dev/mysql_data/mysql #-n参数，表并不会实际执行文件系统操作
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
67108864 inodes, 268434432 blocks
13421721 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
8192 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848e2fsck -b 32768 /dev/mysql_data/mysql #尝试用32768超级块，重建超级块，注意该命令有风险，最为最后决断之操作e2fsck -b 78675968 /dev/mapper/mysql_data-mysql #如下所示，重建失败
e2fsck 1.42.9 (28-Dec-2013)
e2fsck: Invalid argument while trying to open /dev/mapper/mysql_data-mysqlThe superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:e2fsck -b 8193 <device>#终极大招
mke2fs -S /dev/mapper/mysql_data-mysql
mke2fs 1.42.9 (28-Dec-2013)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
67108864 inodes, 268434432 blocks
13421721 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
8192 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848Allocating group tables: done
Writing superblocks and filesystem accounting information: done tune2fs -l /dev/mysql_data/mysql #验证，检查文件系统
tune2fs 1.42.9 (28-Dec-2013)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a460879d-a6a7-4f64-9fca-29a6a184d1f1
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 67108864
Block count: 268434432
Reserved block count: 13421721
Free blocks: 264204269
Free inodes: 67108864
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 960
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Tue Oct 3 01:42:18 2023
Last mount time: n/a
Last write time: Tue Oct 3 01:48:35 2023
Mount count: 0
Maximum mount count: -1
Last checked: Tue Oct 3 01:42:18 2023
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: f55bc2d5-b091-4311-a198-7d7cf9ec8b2d#修复文件系统
e2fsck -fy /dev/mysql_data/mysql #结果恢复失败e2fsck 1.42.9 (28-Dec-2013)
Resize inode not valid. Recreate? yesPass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear? yes2.3、主从切换，使用从库
#正常需要先将主库只读set global read_only=ON;
set global super_read_only=ON;#从库确认同步状态正常
show slave status\G #输出如下
Slave_IO_Running，Slave_SQL_Running状态为YES，Seconds_Behind_Master为0#从库停掉复制进程并清空主从信息stop slave;
reset slave all; #提前备份relay-log;或
RESET MASTER; #清除从服务器上的binlog文件和索引；主服务器有硬件故障，无法清除binlog日志，需要手动备份binlog日志，并复制到另一台服务器上；
RESET SLAVE; #清除从服务器上的主从状态信息set global read_only=off;
set global super_read_only=off;#主库降级未备库，主库上执行CHANGE MASTER TO MASTER_HOST='172.18.1.19',MASTER_USER='repl',MASTER_PORT=3306,MASTER_PASSWORD='xxx',master_auto_position=1 ;
start slave;
show slave status\G注意：出现故障后不要重启，不要重启，不要重启！！！
三、附录
3.1、xfs和ext4的区别
centos7默认文件系统是xfs， xfs是一种非常优秀的日志文件系统，它是SGI公司设计的。xfs被称为业界最先进的、最具可升级性的文件系统技术；xfs是一个64位文件系统，最大支持8EB减1字节的单个文件系统，实际部署时取决于宿主操作系统的最大块限制。对于一个32位Linux系统，文件和文件系统的大小会被限制在16TB；xfs在很多方面确实做的比ext4好，ext4受限制于磁盘结构和兼容问题，可扩展性和scalability确实不如xfs。
centos6默认文件系统是ext4， ext4是第四代扩展文件系统（英语：Fourth EXtended filesystem，缩写为ext4）是linux系统下的日志文件系统，是ext3文件系统的后继版本（ centos5默认文件系统是ext3）； ext4的文件系统容量达到1EB，而文件容量则达到16TB。理论上支持无限数量的子目录；
3.2、LVM 云盘扩容
云盘扩容
fdisk /dev/xxx #磁盘分区扩容
pvresize /dev/xxx #卷扩容
lvextend -L +增加容量 逻辑卷路径
![[MAUI程序设计] 用Handler实现自定义跨平台控件](https://img-blog.csdnimg.cn/img_convert/21259ec992eda22dfb495978aadce026.png)
