千万级MongoDB集合重建索引必须采用滚动构建方案，因其能避免主节点CPU/IO飙升、oplog积压及从节点失联；但需严格满足三个硬性条件：oplogSizeMB充足、副本集至少3个有效数据节点、目标节点磁盘剩余空间≥集合数据1.8倍。
千万级集合重建索引时，直接在主节点上执行 createIndex 或 reIndex 极大概率触发 CPU/IO 飙升、oplog 积压、从节点同步延迟甚至失联——这不是配置问题，而是 WiredTiger 引擎在全量扫描+排序+写入阶段的固有压力。滚动构建是目前 MongoDB 副本集环境下唯一可控的降影响方案，但它不是“开个开关就自动变慢”，而是一套需人工干预、有明确约束条件的操作流程。
滚动构建前必须验证的三个硬性条件
不满足任一条件，滚动构建反而比默认方式更危险：
-
oplogSizeMB必须足够大，确保索引构建期间从节点不会因 oplog 截断而无法追上主节点；经验公式：oplogSizeMB > (预计构建时间小时数) × (每小时平均写入 oplog 字节数) × 1.5 - 副本集至少有 3 个数据节点（不能含仲裁节点），且所有从节点
priority > 0、hidden: false、votes: 1—— 滚动过程依赖选举，隐藏节点或无投票权节点会导致 reconfig 失败 - 目标从节点的磁盘剩余空间 ≥ 当前集合数据大小的 1.8 倍（WiredTiger 构建索引会额外占用约 0.8× 数据体积的临时空间）
滚动构建实际操作步骤（以副本集为例）
核心思路是：把一个从节点临时摘出副本集，作为独立 mongod 实例完成索引构建，再重新加回。全程不碰主节点，也不触发全局锁。
- 在主节点执行
rs.conf()查看成员数组索引，记下要操作的从节点位置（比如cfg.members[1]） - 运行以下命令临时降权并隐藏该节点：
var cfg = rs.conf(); cfg.members[1].priority = 0; cfg.members[1].hidden = true; rs.reconfig(cfg, {force: true}); - 登录该从节点服务器，停掉 mongod：
sudo systemctl stop mongod，然后用新配置重启为独立实例：mongod --port 27018 --dbpath /var/lib/mongodb --bind_ip localhost
- 连上
localhost:27018，对目标集合执行db.collection.createIndex({field: 1}, {background: true})—— 此处必须加background: true，否则独立实例会阻塞整个进程 - 索引完成后，停掉独立 mongod，改回原配置启动，并在主节点执行
rs.reconfig()恢复其priority和hidden状态
为什么不能在分片集群上直接套用副本集滚动方案？
分片集群里每个 shard 是一个副本集，但 config server 和 mongos 不参与索引构建。常见误操作是只在一个 shard 上滚动构建，结果导致：查询路由失效（Query not supported on sharded collection without index）、explain() 显示 IXSCAN 变成 COLLSCAN、聚合管道报错 Cannot use index to sort。正确做法是：对每个 shard 单独执行上述滚动流程，且必须严格按相同顺序、相同参数构建同名索引，否则 chunk 分发和查询优化器会彻底混乱。
容易被忽略的副作用与监控点
滚动构建不是“静默操作”，它会真实改变集群状态：
- 每次 reconfig 触发选举，主节点切换可能造成最多 30 秒写入中断（即使没报错，应用层也可能收到
NotMasterNoSlaveOk） - 隐藏节点期间，该节点不再接收读请求，但仍在复制 oplog —— 如果此时主节点写入突增，隐藏节点的
optimeDate差值会快速扩大，需监控rs.status().members[n].optimeDate - 构建完成后加回节点，WiredTiger 会触发一次 full resync（而非增量同步），如果数据量大，这个阶段可能持续数小时，且完全不可中断
滚动构建本质是用时间换稳定性，而不是消除影响。真正关键的判断点不在“要不要做”，而在“能不能承受一次节点离线 + 一次强制选举 + 一次全量同步”。线上决策前，务必在同等规格的预发环境走完全流程并记录各阶段耗时。
