AOI数据库归档，删数据 科学操作流程

针对你这个 AOI 采集库（海量数据、一主二从副本集）​ 的场景，下面我给你一套贴近大厂规范、可落地的标准做法，重点解决三件事：

1. 删库/删数据为什么会把集群搞挂
2. 海量时序/采集数据的科学归档与删除方法
3. 生产环境标准操作流程（SOP）+ 灰度/测试环境规范

---

一、为什么“删库”会把 MongoDB 跑不起来（根因复盘）

在一主二从副本集中，dropDatabase / dropCollection 是高危操作，不是工具问题，而是操作对象 + 数据量级 + 副本集机制共同导致的：

常见真正踩坑点（不是工具）

• 直接在 Primary 上 drop 超大库/集合
  • MongoDB 的 drop 会：
    1. 获取全局锁
    2. 清理 WiredTiger 表
    3. 写 oplog（同步到两个 Secondary）
  • 在 几十 G/上百 G 的集合上，可能导致：
    • Primary 卡死
    • Secondary 重放 oplog 超时
    • 心跳超时 → 选举抖动 → 集群不稳定
• 删完立刻删数据目录 / 重启节点
  • 有人发现“磁盘没降”，手动 rm -rf dbpath，导致：
    • mongod.lock 残留
    • 元数据不一致
    • 启动失败
• 在 Secondary 上强制写 / 误当 Primary 操作
  • 副本集配置混乱，节点无法加入

✅ 结论：

不是“控制台 vs 可视化”的问题，而是

“超大集合 + drop + 副本集 + 无归档策略”​ 的必然风险。

---

二、AOI 采集类数据的「科学归档与删除」方案（重点）

AOI 数据特征非常典型：

• 写多读少
• 按时间递增
• 数据量大（每天 N G）
• 旧数据访问频率低
• 允许按时间清理

这类数据绝对不应该用 dropDatabase 来“清理”，正确思路是：

---

✅ 方案一：按时间分集合 / 分库（最推荐）

1️⃣ 按天/月分集合（Time-based Collection）

texttextaoi_data_2026_07_25
aoi_data_2026_07_26

• 插入时按日期路由
• 删除时： jsjsuse aoi_db db.aoi_data_2026_06_01.drop()
• 优点
  • drop 粒度小，影响低
  • 可并行删
  • 不易拖垮 Primary
• 配合
  • TTL 索引（可选）
  • 定时任务（cron / 调度平台）

2️⃣ 按时间分库（更彻底）

texttextaoi_2026_07
aoi_2026_06

• 删除整个库 = 删除旧月份
• 可结合 滚动重建 Secondary​ 回收磁盘

---

✅ 方案二：TTL 索引（自动过期，低风险）

适合对删除实时性要求不高的场景：

jsjsdb.aoi_data.createIndex(
  { createTime: 1 },
  { expireAfterSeconds: 60 * 60 * 24 * 90 } // 90 天
)

• MongoDB 后台线程逐步删除
• 不会一次性锁库
• 对副本集友好

⚠️ 注意：

• TTL 删除也会有 oplog
• 超大数据量建议配合分集合使用

---

✅ 方案三：归档冷数据（合规 + 降本）

AOI 数据通常不能真删，要归档：

1. 热数据：MongoDB（最近 7~30 天）
2. 温数据：对象存储 / HDFS / 时序库（30~180 天）
3. 冷数据：磁带 / 低成本存储（>180 天）

流程示例：

• mongodump --query '{createTime:{$lt:ISODate("2026-01-01")}}'
• 压缩上传到 OSS / MinIO
• 校验完整性
• 再删除 MongoDB 中对应集合

---

✅ 方案四：用“滚动删除”替代一次性 drop

如果必须删大集合：

1. 先 renameCollection 改名 jsjsdb.aoi_data.renameCollection("aoi_data_to_drop")
2. 业务切到新集合
3. 后台分批删：
   • 小集合直接 drop
   • 大集合用 deleteMany + 时间范围分批
4. 观察：
   • CPU / IO / 复制延迟
   • oplog window

---

三、生产环境标准 SOP（大厂规范版）

✅ 1. 环境分层（必须满足）

环境	用途	数据规模
Dev	开发自测	小
Test	功能验证	中等
Staging	准生产（同规格）​	接近生产​
Prod	生产	真实

❗ 所有删库/归档脚本 必须先在 Staging 跑通

---

✅ 2. 变更管理流程（生产级）

每一次“删数据 / 删库 / 归档”都应按 变更工单​ 管理：

1. 提交变更申请
   • 目的
   • 影响范围
   • 数据量评估
   • 回滚方案
2. 评审
   • DBA
   • 业务负责人
   • 运维
3. 测试环境验证
   • 脚本执行耗时
   • 资源占用
   • 副本集影响
4. 灰度执行
   • 先对一个 Secondary 观察
   • 再 Primary（低峰期）
5. 备份先行 bashbashmongodump --oplog
6. 执行 + 监控
   • 磁盘
   • 复制延迟
   • 业务错误率
7. 复盘
   • 耗时
   • 异常
   • 优化点

---

✅ 3. 删除前 Checklist（可直接用）

• [ ] 是否在 Staging 环境验证过
• [ ] 是否确认连接的是 Primary
• [ ] 是否指定 writeConcern: majority
• [ ] 是否已 mongodump 备份
• [ ] 是否在 业务低峰期
• [ ] 是否通知相关业务方
• [ ] 是否有 回滚方案
• [ ] 是否监控 oplog / 复制延迟

---

四、针对你这次事故的“正确姿势”总结

❌ 错误做法

一主二从 → 控制台连 Primary → dropDatabase 大库 → 磁盘没降 → 手动删文件 → 起不来

✅ 正确做法

• AOI 数据按 时间分集合/分库​
• 旧数据 TTL + 归档 + 分批删​
• 删除前 Staging 验证 + 备份 + 灰度​
• 绝不手动 rm dbpath
• 工具无所谓，流程才是一切

---

如果你愿意，我可以帮你：

• 设计一套 AOI 数据采集库的 MongoDB 集合命名 + 归档策略
• 或写一份 “MongoDB 大表安全删除 SOP 文档”（可直接给团队用）
• 或给你一个 分集合 + 自动 drop 的定时任务示例

你可以告诉我你们现在的 数据保留周期 / 每天写入量 / 磁盘大小，我可以帮你算一套更具体的归档参数。