如何通过滚动构建方案减少MongoDB千万级集合索引重建的影响？

本文共计1125个文字，预计阅读时间需要5分钟。

在重建索引时，WiredTiger 引擎通常直接在主节点上执行 `createIndex` 或 `reIndex` 操作。这通常会导致CPU和IO资源的显著增加，可能会引起暂时的性能下降和oplog的积累。同时，可能会因为节点同步延迟而导致连接中断——这不是配置问题，而是WiredTiger在执行全量扫描、排序和写入阶段时固有的压力。

滚动构建前必须验证的三个硬性条件

不满足任一条件，滚动构建反而比默认方式更危险：

• 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（而非增量同步），如果数据量大，这个阶段可能持续数小时，且完全不可中断

滚动构建本质是用时间换稳定性，而不是消除影响。真正关键的判断点不在“要不要做”，而在“能不能承受一次节点离线 + 一次强制选举 + 一次全量同步”。线上决策前，务必在同等规格的预发环境走完全流程并记录各阶段耗时。