如何通过滚动构建方案减少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 实例完成索引构建，再重新加回。全程不碰主节点，也不触发全局锁。