节点卡在STARTUP2或RECOVERING主因是同步流程阻断，需检查磁盘空间、oplog完整性、syncSource可用性、防火墙及WiredTiger缓存，而非带宽不足。
初始化同步卡在 STARTUP2 或 RECOVERING 怎么办
节点长期停在 STARTUP2 或反复进出 RECOVERING，说明它根本没进入数据拉取阶段，更不是“慢”，而是同步流程被阻断。常见原因不是网络带宽小，而是本地环境不满足基础条件。
- 检查磁盘空间：
dbPath所在分区剩余空间必须 ≥ 当前数据集大小 × 1.5（WiredTiger 压缩 + 临时 oplog 缓存） - 确认
local.oplog.rs是否损坏：执行db.oplog.rs.stats()，若报错collection not found或Invalid namespace，说明 oplog 元数据异常，需清空local目录后重启 - 验证 syncSource 是否可用：在该节点执行
rs.status().members[n].syncSourceHost，若为空或指向已下线节点，手动指定源（启动时加--syncSourceHost primary-host:27017） - 避免防火墙拦截：Secondary 启动后会主动连 Primary 的
27017，同时也需要反向连 Primary 的内部通信端口（如27018，取决于replSet配置）
初始同步期间 applyOps 阶段 CPU 或 I/O 卡死
克隆完数据后卡在 RECOVERING 状态不动，db.serverStatus().metrics.repl.apply.queued 持续 > 0，说明 oplog 回放环节被拖住。这不是网络问题，而是 Secondary 本地资源被其他任务抢占。
- 禁用非必要后台任务：停掉备份脚本、慢查询监控、
diagnostic.data自动采集（通过setParameter关闭diagnosticDataCollectionEnabled） - 限制并发读：Secondary 默认允许大量并发读请求，会挤占
applyOps线程的 CPU 时间片。执行db.runCommand({setParameter: 1, maxConcurrentOps: 64})（默认 512，压到 64–128 更稳妥） - 检查 WiredTiger cache：若
db.serverStatus().mem.resident接近系统内存上限，且wiredTiger.cache.maximum bytes currently in use持续 > 90%，说明 cache 不足，回放大文档时频繁刷盘——调大--wiredTigerCacheSizeGB或临时降级写入压力 - 索引构建拖慢回放：如果主节点近期建了大集合索引，Secondary 会在 applyOps 阶段同步重建，耗时极长。可先在 Primary 上用
background: true创建索引，再触发同步
如何缩短 initial sync 整体耗时
纯逻辑同步（克隆 + 回放）本身不可并行，但能绕过它——MongoDB Enterprise 支持基于文件拷贝的初始同步，自管理部署中也可手动复用已有节点的数据目录，跳过网络拉取和逐文档插入。
- 优先采用文件拷贝法：停掉目标节点 → 用
rsync -av --delete从一个健康 Secondary 拷贝整个dbPath（排除mongod.lock和journal/）→ 启动 mongod。注意：源节点必须比目标节点新（optimeDate更晚），否则同步会失败 - 禁止在同步中启用 change stream：
local.oplog.rs在 initial sync 中会被截断，依赖 oplog 的监听服务（如 Kafka Connector）会中断。同步完成后再启用 - 不要调
numInitialSyncAttempts：这个参数只控制重试次数，不影响速度。改它解决不了任何性能瓶颈 - 分片集群里尤其要关掉
secondaryPreferred：否则新加入的 Shard Secondary 一边拉本 Shard 的 oplog，一边扛业务读，I/O 直接打满——同步期间所有读应强制走primary
扩容 oplog 不能解决 initial sync 慢，但能防它反复失败
oplog 太小不会让 initial sync 变慢，但它会让同步中途失败——当 Secondary 还没克隆完，Primary 的 oplog 就已覆盖掉起点记录，导致出现 OplogStartMissing，被迫重头开始。
- 验证是否真缺 oplog：在待同步节点执行
db.oplog.rs.findOne({ts: ObjectId("...")})，其中ObjectId来自 Primary 的rs.status().members[0].optime.ts；返回null即确认丢失 - 4.4+ 版本立即扩容：在 Primary 执行
db.adminCommand({replSetResizeOplog: 1, size: 20480})（20GB），避免后续同步再断 - 旧版本别碰
captrunc：直接删local.oplog.rs或用命令清空会破坏 capped 属性，mongod 启动失败。只能滚动重建：逐个下线 Secondary → 停 mongod → 删除local/oplog.rs.wt文件 → 加--oplogSize参数重启 → 等它完成 initial sync 再处理下一个
真正卡住 initial sync 的，从来不是 oplog 大小，而是磁盘 I/O 能力、WiredTiger cache 分配、以及有没有其他进程在跟复制抢资源。盯着 optimeDate 看延迟没用，得看 rs.status().members[n].lastHeartbeatMessage 里是不是一直写着 “syncing to…” 却毫无进展。
