db.killop() 在副本集上大概率失败，因其仅能终止当前连接所在节点（通常是主节点）上由该连接发起的操作，无法传播到从节点、穿透wiredtiger长事务或清理system.profile残留记录。
不能直接用 db.killOp() 终止副本集上的大型聚合 —— 它只在 mongos 或主节点上生效，且对已分发到从节点的聚合阶段无效。
为什么 db.killOp() 在副本集上大概率失败
在副本集里，db.killOp() 只能终止当前连接所在节点（通常是主节点）上由该连接发起的操作。但大型聚合（尤其是含 $lookup、$facet 或大量内存消耗的 $group）可能：
- 已在从节点上完成部分阶段，但主节点仍卡在游标收拢或结果序列化环节
- 触发了 WiredTiger 内部的长时间锁（如 snapshot 长持有），
killOp无法穿透到底层存储引擎 - 使用了
allowDiskUse: true，临时文件写入未完成时 kill 会导致残留文件和后续空间误判
优先用 maxTimeMS 防患于未然
真正“优雅”的终止，是提前设限，而不是事后补救。所有聚合操作都应带超时：
- 在
db.collection.aggregate()调用末尾加.maxTimeMS(60000)（单位毫秒） - 若通过
db.runCommand({aggregate: ...})发起，必须把maxTimeMS: 60000放在命令文档顶层，不是管道内 - 注意：
maxTimeMS对$out或$merge阶段不生效 —— 这些写入阶段需单独监控
示例：
db.orders.aggregate([<br> { $match: { status: "pending" } },<br> { $group: { _id: "$region", total: { $sum: "$amount" } } }<br>], { maxTimeMS: 30000 })
真卡死了，怎么最小影响地干预
确认聚合卡死后（比如 db.currentOp({secs_running: {$gt: 300}}) 查到耗时 >5 分钟的 op），按顺序尝试：
- 先查
op字段是否为getmore：若是，说明只是游标拉取慢，可安全 kill ——db.killOp(<opid>)</opid>有效 - 若
op是command且secs_running > 300，检查active: true和waitingForLock: true—— 此时 kill 很可能无响应，应改用db.adminCommand({shutdown: 1, force: true})重启该节点（仅限从节点） - 绝对不要在主节点上直接 shutdown；如主节点卡死，先用
rs.stepDown()主动降级，再对原主节点执行维护式重启
容易被忽略的陷阱
很多人以为 db.killOp() 是万能刹车，但在 MongoDB 6.0 副本集中它实际作用域非常窄：
- 不传播到从节点 —— 卡在从节点上的聚合阶段不会被终止
- 不中断 WiredTiger 的内部事务 —— 如果聚合触发了长事务（例如大范围
$lookup关联），kill 后仍可能持续占用内存和句柄 - 不清理
system.profile中的记录 —— 卡死操作留下的 profile 条目会持续膨胀，建议定期db.setProfilingLevel(0)关闭分析器
