MongoDB副本集本身不提供自动扩容存储空间能力，所谓“自动”必须由外部监控+脚本驱动，LVM是实现在线拉伸数据目录所在卷的可靠底层手段；关键前提是副本集各节点数据目录必须挂载在LVM逻辑卷上，且路径与权限一致，否则无法在线扩容。
MongoDB副本集本身不提供“自动扩容存储空间”能力，所谓“自动”必须由外部监控+脚本驱动，而LVM是实现在线拉伸数据目录所在卷的可靠底层手段。关键在于：副本集节点的数据目录必须挂载在LVM逻辑卷上，且所有节点使用一致的存储路径与权限模型。
确认副本集节点是否运行在LVM逻辑卷上
这是前提，否则后续所有操作都无意义。在每个副本集成员上执行：
- 用
df -h /var/lib/mongodb（或你的实际storage.dbPath）查出挂载点对应设备； - 用
lsblk或sudo lvdisplay确认该设备是否为/dev/vg_name/lv_name形式； - 若显示为
/dev/sda1或/dev/nvme0n1p1这类物理分区，则不支持在线拉伸，需先迁移至LVM（风险高，建议停机操作）。
常见误判：df 显示挂载点是 /var/lib/mongodb，但实际是软链接到 /mnt/data —— 那么真正要检查的是 /mnt/data 所在设备。
在线拉伸LVM逻辑卷并扩展文件系统
只要逻辑卷和文件系统支持，此过程无需停止 mongod 服务（WiredTiger 允许后台文件增长）。但务必确保磁盘底层有足够空闲PE（Physical Extents）。
- 先扩展逻辑卷（例如加20G）：
sudo lvextend -L +20G /dev/vg_mongodb/lv_data； - 再扩展文件系统：
• ext4：用sudo resize2fs /dev/vg_mongodb/lv_data；
• xfs：用sudo xfs_growfs /var/lib/mongodb（注意：传入的是挂载点，不是设备路径）； - 验证：
df -h /var/lib/mongodb应立即显示新增容量；sudo lvs确认LV大小已更新。
容易踩的坑：resize2fs 对xfs无效；xfs_growfs 必须指定挂载点，传设备路径会报错 XFS: file system is mounted; use -d option to force（别加 -d）。
让MongoDB感知并利用新增空间
WiredTiger 引擎不会主动“清空旧空间”，它只会在写入新数据、执行压缩或checkpoint时逐步复用释放的空间。你不需要重启 mongod，但要注意：
- 新增空间对现有集合立即可用，但
db.stats()中的dataSize和storageSize不会立刻变化； - 若长期未写入，可用空间虽增加，但
du -sh /var/lib/mongodb可能仍偏高 —— 这是正常现象，WiredTiger 的预分配与碎片导致； - 可手动触发一次 checkpoint 加速空间回收：
db.adminCommand({fsync: 1})（仅限主节点，且会短暂阻塞写入）。
真正影响容量利用率的是 storage.wiredTiger.engineConfig.cacheSizeGB 设置：它控制内存缓存，不直接影响磁盘空间，但过小会导致频繁刷盘，间接加剧I/O压力。
自动化监控与触发脚本的关键点
所谓“自动扩容”，本质是定时检测 + 条件触发 + 执行LVM拉伸命令。但生产环境必须加严控：
- 阈值不能设太低（如15% 并搭配
mongostat观察netIn/netOut判断是否真有持续写入压力； - 脚本中必须校验
vgdisplay vg_mongodb | grep "Free PE"是否足够，避免lvextend失败后静默退出； - 每个副本集节点必须单独执行拉伸（不能只拉主节点）—— 否则从节点同步时可能因磁盘满而中断复制；
- 强烈建议在拉伸前自动执行
mongodump --oplog（主节点）和rs.printSecondaryReplicationInfo()（确认延迟
最易被忽略的一点：SELinux 或 AppArmor 策略可能阻止 mongod 写入新扩展的块设备区域，拉伸后若出现 Permission denied 错误，需运行 sudo restorecon -Rv /var/lib/mongodb（SELinux）或检查 AppArmor 日志。
