AD-CAMPUS6.5, 集群一节点报磁盘利用率高 /var/lib/ssdata。
- 0关注
- 0收藏，119浏览
排查步骤：
1. 登录问题节点，确认磁盘占用详情：
bash
df -h /var/lib/ssdata
du -sh /var/lib/ssdata/oasis/mongodb/shard/*
2. 检查MongoDB日志大小：
bash
ls -lh /var/lib/ssdata/oasis/mongodb/shard/log/
若日志文件过大，可清理旧日志（保留最近几天）。
3. 检查数据增长原因：
进入MongoDB容器或使用mongo命令查看集合大小：
bash
mongo --host <节点IP> --port <端口> --eval "db.stats()"
关注大集合，如性能监控、终端数据等。
4. 确认是否有备份或临时文件残留：
bash
find /var/lib/ssdata/oasis/mongodb/shard -type f -size +1G
处理方法：
若为日志问题：清理或轮转日志，修改MongoDB配置限制日志大小。
若为数据增长：联系H3C技术支持评估数据保留策略，可能需要清理过期数据或扩容磁盘。
紧急释放空间：可清理MongoDB的oplog（如确认安全）或归档旧数据。
注意：操作前备份关键数据，避免影响集群业务。
/var/lib/ssdata/oasis/mongodb/shard/datadir占156G
/var/lib/ssdata/oasis/mongodb/shard/datadir占156G
产生磁盘高占用常见根因
- 过期时序事件 / 终端上报数据持续累积 审计日志、终端上下线、安全事件、流量分析数据 TTL 老化删除后，WiredTiger 存储引擎只标记空闲，不会自动归还操作系统磁盘，形成大量磁盘碎片，物理磁盘不会自动缩小阿里云帮助...。
- TTL 索引失效，历史数据没有自动过期清理，旧事件持续写入，数据量持续膨胀。
- MongoDB 分片 Balancer 均衡迁移 chunk，大量 moveChunk 产生碎片；数据倾斜，单分片数据堆积。
- 版本 BUG：部分 AD‑Campus6.5 早期补丁版本 Oasis 组件 TTL 清理任务异常，旧数据无法自动回收。
- 接入终端数量大，上报频率高，事件采集量超出规划存储容量。
⚠️重要：不要直接手动删除 shard 目录下任何文件，会直接损坏 MongoDB 数据库，导致 Oasis、分析、资产功能整体不可用。
二、前置检查步骤（生产必须先做）
1）磁盘与目录统计
登录该故障节点 SSH
df -h /var/lib/ssdata
du -sh /var/lib/ssdata/oasis/*
du -sh /var/lib/ssdata/oasis/mongodb/shard/*
2）检查 Oasis 容器 / 进程状态
AD‑Campus6.5 基于容器部署，确认 mongodb‑shard 实例状态正常，无反复重启
kubectl get pods -n oasis | grep mongo
3）备份（必做，操作前）
优先通过 AD‑Campus 页面执行Oasis 组件完整备份；不要直接操作底层数据文件。
4）确认版本补丁
确认 AD‑Campus 6.5 的小版本补丁，查看 release notes 是否存在 Oasis mongodb TTL 清理 BUG，如果存在优先升级官方补丁包。
三、定位是 “真实数据大” 还是 “碎片占空间”
进入 mongodb‑shard 容器内部，连接 mongod，执行
db.stats()与集合 stats，区分：totalSize真实业务数据大小 vsstorageSize磁盘物理占用； 如果file bytes available for reuse数值很大，代表大量碎片空闲未释放给操作系统，就是碎片问题MongoDB。
⚠️AD‑Campus 内置 MongoDB 不建议无指导直接手工执行
compact；compact 会消耗大量 IO，业务高峰期会造成 Oasis 分析、资产、审计功能卡顿，必须业务低窗口操作。
四、分场景处理方案
场景 A：TTL 过期数据没有自动清理（真实业务数据持续增长）
- 在 AD‑Campus 页面，进入【Oasis 平台‑系统配置】，调整事件、审计、终端日志保留天数，缩短保存周期（默认 90 天，可按需改成 30‑45 天）。
- 修改保存周期后，TTL 索引会逐步批量删除过期文档；删除完成后只是标记空闲，磁盘不会立刻释放，碎片依然存在。
- 如果 TTL 任务异常不执行，需要联系 400 确认是否需要重建 TTL 索引（禁止自行在生产库删除 / 新建索引）。
场景 B：业务数据量不大，但碎片巨大（storageSize 远大于真实 dataSize）
两种方案：
方案 1（官方推荐优先）：磁盘扩容
/var/lib/ssdata是数据盘，优先 LVM 扩容卷，MongoDB 会复用内部空闲碎片给新业务写入，不需要立刻回收物理空间；这是生产环境风险最低方案。
碎片空间 MongoDB 内部可以复用，只是不还给 OS；新写入数据优先消耗碎片空闲块，不一定会继续涨磁盘。
方案 2：碎片回收（低业务窗口，需要 400 工程师评估指导）
不能直接在 AD‑Campus 自行操作，属于组件内部数据库维护。
- 方式一：副本集滚动 resync 重新同步数据，重建数据文件，释放碎片（官方推荐的分片副本集回收碎片手段）MongoDB。
- 方式二：对集合执行
compact压缩命令；副本集需要逐台 secondary 执行，再切换主节点，再压缩旧主；IO 压力很大，大集合耗时很长MongoDB。
❗不要网上直接复制 MongoDB 命令自行执行，AD‑Campus 的 Oasis 是封装好的业务库，错误操作会导致资产、审计、终端分析功能损坏。
场景 C：单分片数据倾斜，数据不均衡
检查 MongoDB 分片 Balancer 是否正常开启，是否存在 chunk 迁移异常；需要 400 登录数据库检查分片数据分布，调整分片策略。
五、紧急临时风险规避（磁盘持续上涨告警）
- 临时调低 Oasis 各类事件存储保留时间，减少新增数据压力。
- 如磁盘即将写满：优先扩容
/var/lib/ssdata存储卷，不要做删除文件操作。 - 观察 pod 状态，如果 mongodb‑shard 因为磁盘满发生 CrashLoopBackOff，会导致资产识别、终端分析、安全分析全部失效。
六、长期预防建议
- AD‑Campus 规划阶段，根据接入终端规模合理规划 ssdata 数据盘容量；大量终端场景建议 ssdata 盘≥1TB。
- 定期升级 AD‑Campus 官方补丁，修复 Oasis 组件 TTL 清理、数据库相关 BUG。
- 监控
/var/lib/ssdata磁盘使用率，设置 80% 告警阈值。 - 不要随意调大 Oasis 事件存储保留时长，保留越长 mongodb‑shard 磁盘压力越大。
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明