企业官网建设流程全解析

1. LVM扩容实战：从VG扩展到文件系统调整

刚入行那会儿，我最怕的就是服务器突然报磁盘空间不足。传统分区就像固定大小的集装箱，要么拆东墙补西墙，要么就得停机迁移数据。直到掌握了LVM的动态扩容，才真正体会到什么叫"存储自由"。今天就用我在IDC机房踩坑的经验，手把手教你玩转LVM扩容。

先看个真实案例：去年双十一前，某电商平台的日志服务器突然告警，/var分区只剩5%空间。如果用传统方式，至少要停服务4小时。而我们用LVM三招搞定：

1. 往服务器插了块新硬盘
2. 10分钟完成VG扩容
3. 在线扩展了200GB空间

整个过程业务零中断，这就是LVM的魅力。下面分解操作步骤：

1.1 物理卷(PV)的扩容准备

假设我们已有VG组vg_data，现在要加块新硬盘/dev/sdc。首先得让新硬盘被LVM识别：

# 查看新硬盘是否被系统识别 lsblk | grep sdc # 创建物理卷（相当于给硬盘打上LVM标签） pvcreate /dev/sdc

这里有个坑我踩过三次：如果硬盘已有分区表，直接pvcreate会报错。保险做法是先清空：

# 万能的dd命令清空硬盘头信息 dd if=/dev/zero of=/dev/sdc bs=1M count=100 # 更专业的wipefs方式 wipefs -a /dev/sdc

1.2 卷组(VG)的灵活扩展

有了PV后，扩展VG就像往游泳池里注水：

# 查看现有VG空间 vgdisplay vg_data | grep "Free PE" # 将新PV加入现有VG vgextend vg_data /dev/sdc # 验证扩容结果（重点看Free PE变化） vgdisplay vg_data

遇到过最棘手的情况是VG的PE Size不匹配。比如原VG的PE是4MB，新PV默认用4MB，但若之前有人用-s参数改过PE大小，就必须保持统一。这时要用：

# 创建PV时指定PE大小（需与原VG一致） pvcreate --setphysicalvolumesize 4M /dev/sdc

1.3 逻辑卷(LV)的在线扩容

VG有了空闲空间，就能给LV"喂食"了。以扩容/home分区为例：

# 查看当前LV路径（重要！） lvdisplay | grep "LV Path" # 扩展LV容量（注意单位G/M的区别） lvextend -L +50G /dev/vg_data/lv_home # 对于xfs文件系统 xfs_growfs /home # 对于ext4文件系统 resize2fs /dev/vg_data/lv_home

去年有次扩容，我忘了执行xfs_growfs，虽然lvdisplay显示容量增加，但df -h就是不变。这种隐性问题最危险，因为实际数据可能已经写到未格式化的空间。所以务必记住：

• XFS：先扩LV，再扩文件系统
• EXT4：顺序无所谓，但建议保持一致

2. LVM收缩操作：安全瘦身指南

相比扩容，收缩操作就像给运行中的汽车换轮胎，风险系数高了三倍不止。我有次收缩数据库分区，差点造成数据丢失。下面分享安全收缩的"慢三步"原则。

2.1 收缩前的必要检查

必须确认三件事：

1. 文件系统类型（xfs不支持收缩！）
2. 当前使用量（留至少20%缓冲空间）
3. 是否有快照依赖

# 查看文件系统类型 blkid /dev/vg_data/lv_home # 检查使用量（重点看Used%） df -h /home # 检查快照 lvdisplay | grep "Snapshot"

2.2 EXT4文件系统的收缩实战

以/home分区从200G收缩到150G为例：

# 1. 卸载分区（必须步骤！） umount /home # 2. 强制文件系统检查 e2fsck -f /dev/vg_data/lv_home # 3. 先收缩文件系统（重要顺序！） resize2fs /dev/vg_data/lv_home 150G # 4. 再收缩LV lvresize -L 150G /dev/vg_data/lv_home # 5. 重新挂载 mount /home

曾遇到个经典问题：resize2fs时报"target size smaller than minimum"。这是因为ext4的inode等元数据占据了固定空间。解决方法是用mke2fs查看最小尺寸：

# 获取文件系统最小尺寸 mke2fs -n /dev/vg_data/lv_home

2.3 一键收缩的便捷方案

对于熟练后可以尝试精简命令：

# 自动计算文件系统大小的收缩方式 lvresize -r -L 150G /dev/vg_data/lv_home

但这个方案有局限：

1. 不能指定精确大小，只能按文件系统需求收缩
2. 某些旧版LVM不支持-r参数
3. 无法处理复杂情况（如快照存在时）

3. 生产环境中的LVM管理技巧

在金融行业做了五年运维，总结了这些血泪经验：

3.1 容量规划黄金法则

1. VG的PE Size统一用16MB（平衡管理开销和灵活性）
2. 单个LV不超过10TB（避免备份恢复困难）
3. 保留至少10%的VG空闲空间（应对突发扩容）

创建VG时就该考虑未来：

# 最佳实践VG创建命令 vgcreate -s 16M vg_data /dev/sd[b-c]

3.2 监控与报警策略

通过这些指标提前预警：

# 每日检查脚本模板 #!/bin/bash CRITICAL=90 WARNING=80 for vg in $(vgs --noheadings -o vg_name); do USE_PERCENT=$(vgs --noheadings -o vg_free $vg | awk '{print $2}') if [ ${USE_PERCENT%%.*} -ge $CRITICAL ]; then echo "CRITICAL: VG $vg only has $USE_PERCENT free" elif [ ${USE_PERCENT%%.*} -ge $WARNING ]; then echo "WARNING: VG $vg has $USE_PERCENT free" fi done

3.3 故障恢复三板斧

当LVM出现异常时：

1. 先备份元数据：

   vgcfgbackup -f /root/vg_backup vg_data

2. 尝试修复：

   vgck vg_data vgchange -a y vg_data

3. 终极方案：

   vgimportclone -n vg_data_new /dev/sdc

4. 特殊场景下的LVM玩法

4.1 交换分区动态扩容

当OOM频繁时，快速扩展swap：

# 查看当前swap swapon --show # 创建swap LV（如果还没有） lvcreate -L 4G -n lv_swap vg_data mkswap /dev/vg_data/lv_swap swapon /dev/vg_data/lv_swap # 在线扩容步骤 swapoff /dev/vg_data/lv_swap lvresize -L 8G /dev/vg_data/lv_swap mkswap /dev/vg_data/lv_swap swapon /dev/vg_data/lv_swap

4.2 跨多硬盘的条带化

对数据库类应用，可以用条带化提升IO：

# 创建条带化LV（stripe_size单位KB） lvcreate -L 100G -i 2 -I 256 -n lv_db vg_data /dev/sdb /dev/sdc

这里-i指定PV数量，-I指定条带大小。有个性能调优技巧：将-stripe-size设置为DB页大小的整数倍，比如MySQL默认16KB，就设-I 16。

4.3 快照备份实战

创建仅占用变化空间的快照：

# 创建50G的快照（实际占用随变化增长） lvcreate -s -n lv_home_snap -L 50G /dev/vg_data/lv_home # 挂载快照（注意ro选项） mount -o ro /dev/vg_data/lv_home_snap /mnt/snapshot # 删除快照（合并变化） umount /mnt/snapshot lvremove /dev/vg_data/lv_home_snap

去年用这个方案，我们把备份窗口从4小时缩短到15分钟。关键点在于：

1. 快照大小预估变化量的2倍
2. 快照存活时间不超过24小时
3. 定期检查快照使用率