STARTUP2不是卡死，而是MongoDB正在执行初始同步的第一阶段：完整克隆所有非local数据库的文档；日志持续输出“Cloning collection”或“Documents copied”即表明克隆正常进行，耗时取决于数据量、同步源磁盘吞吐及网络带宽稳定性。
STARTUP2 不是卡死，而是正在克隆数据
节点显示 STARTUP2 状态时，MongoDB 正在执行初始同步（initial sync）的第一阶段：完整克隆所有非 local 数据库的文档。这不是故障，而是预期行为——只要日志里持续出现类似 Cloning collection: mydb.users 或 Documents copied: 1245678/9876543 的输出，就说明克隆仍在进行。
克隆耗时取决于：
– 数据总大小（尤其 _id 和索引字段体积）
– 同步源节点的磁盘吞吐能力（SSD > HDD）
– 网络带宽与稳定性（建议 ≥1Gbps，延迟 – 目标节点 wiredTigerCacheSizeGB 是否足够（默认 1GB 常不足，大库建议 ≥4GB）
注意：rs.status() 中的 optime 字段在 STARTUP2 阶段不更新；不要靠它判断进度——它只在进入 SECONDARY 后才有意义。
如何确认当前卡在克隆阶段而非索引阶段
打开 MongoDB 日志（如 /var/log/mongodb/mongod.log），搜索以下关键词：
-
Cloning collection→ 表示还在克隆数据 -
Index build: building index或Starting indexing for collection→ 已进入索引构建阶段 -
Finished cloning all collections→ 克隆完成，即将开始建索引
如果日志停在 Cloning collection: xxx 且长时间无新行，检查：
– 同步源是否因 oplog 过小被截断（replSetGetStatus 中 syncSourceHost 变为空）
– 目标节点磁盘空间是否充足（克隆需 ≥ 原数据 1.5 倍临时空间）
– 是否存在网络中断或防火墙拦截（特别是长连接超时）
查看克隆进度的实用命令和指标
无法直接查“已克隆百分比”，但可通过以下方式估算：
- 查日志最新行的文档计数：
grep "Documents copied:" /var/log/mongodb/mongod.log | tail -n 1 - 对比同步源上该集合的文档总数：
db.getSiblingDB("mydb").users.countDocuments({}) - 观察目标节点磁盘写入速率：
iostat -x 2看%util和wkB/s是否持续活跃 - 检查 WiredTiger cache 压力：
db.serverStatus().wiredTiger.cache中关注bytes currently in the cache和maximum bytes configured比值
若 bytes currently in the cache 长期接近上限，且日志频繁出现 WT_CACHE_FULL，说明 cache 不足，需调大 wiredTigerCacheSizeGB 并重启。
别碰 local 数据库，也别删 dbpath
强行中断 STARTUP2（比如 kill -9、删 dbpath、清空 local）会导致：
– 下次启动仍需全量重同步（无增量恢复）
– local.oplog.rs 临时记录丢失，可能触发回滚失败
– 集合元数据损坏，后续 mongod 启动报 new file allocation failure
真正安全的操作只有两个：
– 耐心等（几小时到一两天都正常，尤其 TB 级 + 多复合索引）
– 若确认卡死（日志完全静默超 2 小时 + iostat 显示零写入），再考虑切换同步源：rs.syncFrom("source-host:port")，但前提是源节点健康且 oplog 足够深
最易被忽略的一点：索引构建永远发生在克隆之后，且单集合串行、不可跳过——哪怕你只想要数据不要索引，MongoDB 也不会给你这个选项。
