学习网站免费,前端简历,虚拟币充值 wordpress,淘宝官方网站登录页面一、问题描述
因某次MySQL binlog占用过高扩容时#xff0c;是直接对云盘操作#xff0c;而扩容直接操作了lvm卷而未操作云盘分区#xff0c;并随后执行了扩容的partprobe#xff0c;resize2fs卷等操作#xff1b;最后#xff0c;显示并未扩容成功#xff0c;重启系统后…一、问题描述
因某次MySQL binlog占用过高扩容时是直接对云盘操作而扩容直接操作了lvm卷而未操作云盘分区并随后执行了扩容的partproberesize2fs卷等操作最后显示并未扩容成功重启系统后无法进入包文件系统错误无法加载注释后重启发现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.vgCouldnt find device with uuid gzdJP8-ltvz-l2Kd-WfJD-335J-NrDd-mhwi7w.VG name: mysql_dataDescription: Created *before* executing vgcreate mysql_data /dev/sdb1Backup 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_dataBackup Time: Thu Jun 16 15:19:52 2022File: /etc/lvm/backup/mysql_dataVG name: mysql_dataDescription: Created *after* executing vgsBackup 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 bs512 count1 skip1
#恢复分区表然后输入“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
Couldnt 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
Couldnt find valid filesystem superblock.#找不到超级快使用以下命令查找
mke2fs -n /dev/mysql_data/mysql #-n参数表并不会实际执行文件系统操作
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label
OS type: Linux
Block size4096 (log2)
Fragment size4096 (log2)
Stride0 blocks, Stripe width0 blocks
67108864 inodes, 268434432 blocks
13421721 blocks (5.00%) reserved for the super user
First data block0
Maximum filesystem blocks4294967296
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 size4096 (log2)
Fragment size4096 (log2)
Stride0 blocks, Stripe width0 blocks
67108864 inodes, 268434432 blocks
13421721 blocks (5.00%) reserved for the super user
First data block0
Maximum filesystem blocks4294967296
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? yes
2.3、主从切换使用从库
#正常需要先将主库只读set global read_onlyON;
set global super_read_onlyON;#从库确认同步状态正常
show slave status\G #输出如下
Slave_IO_RunningSlave_SQL_Running状态为YESSeconds_Behind_Master为0#从库停掉复制进程并清空主从信息stop slave;
reset slave all; #提前备份relay-log;或
RESET MASTER; #清除从服务器上的binlog文件和索引主服务器有硬件故障无法清除binlog日志需要手动备份binlog日志并复制到另一台服务器上
RESET SLAVE; #清除从服务器上的主从状态信息set global read_onlyoff;
set global super_read_onlyoff;#主库降级未备库主库上执行CHANGE MASTER TO MASTER_HOST172.18.1.19,MASTER_USERrepl,MASTER_PORT3306,MASTER_PASSWORDxxx,master_auto_position1 ;
start slave;
show slave status\G
注意出现故障后不要重启不要重启不要重启
三、附录
3.1、xfs和ext4的区别
centos7默认文件系统是xfs xfs是一种非常优秀的日志文件系统它是SGI公司设计的。xfs被称为业界最先进的、最具可升级性的文件系统技术xfs是一个64位文件系统最大支持8EB减1字节的单个文件系统实际部署时取决于宿主操作系统的最大块限制。对于一个32位Linux系统文件和文件系统的大小会被限制在16TBxfs在很多方面确实做的比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 增加容量 逻辑卷路径
