卡在STARTUP2不是慢而是同步流程被阻断，需检查dbPath分区剩余空间是否≥数据集大小×1.5、oplog完整性、syncSource可用性、防火墙及WiredTiger缓存。
卡在 STARTUP2 不是“慢”，而是根本没开始同步——流程被阻断，必须逐项排查基础条件是否满足。
检查磁盘空间是否足够
WiredTiger 在 initial sync 期间需要额外空间：克隆数据 + 压缩缓存 + 临时 oplog 缓存。若 dbPath 所在分区剩余空间 STARTUP2。
- 用
df -h /path/to/dbPath确认可用空间 - 用
db.stats()查当前数据集大小（dataSize字段） - 不要只看“够不够存下”，要预留至少 50% 的 buffer，尤其当集合含大量小文档或使用压缩时
验证 local.oplog.rs 是否可读
STARTUP2 阶段需先读取主节点的 local.oplog.rs 元信息来确定同步起点。如果该集合元数据损坏（比如因异常关机、手动删过 local 目录），节点会卡住且无明确报错。
- 在新节点上连 primary 执行
db.oplog.rs.stats() - 若返回
collection not found或Invalid namespace，说明 oplog 元数据异常 - 解决方案：停掉该节点 mongod，清空其
dbPath/local/下所有文件（保留目录结构），再重启
确认 syncSource 是否真实可达
节点启动后会主动向 syncSourceHost 发起连接（默认选 primary，但可能被自动切换）。如果该地址不可达、解析失败、或目标端口被拦截，它就发不出第一个心跳，永远卡在 STARTUP2。
- 执行
rs.status().members[n].syncSourceHost（n 是该节点索引），看返回是否为空或指向已下线节点 - 在该节点机器上运行
mongosh --host <syncsourcehost>:27017 --eval "db.isMaster()"</syncsourcehost>，验证能否直连 - 若不可达，启动时加
--syncSourceHost primary-host:27017强制指定；避免依赖自动发现 - 注意：云环境要同时检查安全组和本地防火墙，
telnet primary-host 27017成功 ≠ 反向通信也通
排查防火墙与端口冲突
副本集成员间所有通信（心跳、oplog 拉取、选举）都走同一个监听端口（默认 27017），且要求双向 TCP 连通。很多故障源于只开了入站、没开回程，或被 iptables/ufw 的兜底规则静默丢包。
- 在新节点执行
sudo ss -tlnp | grep :27017，确认 mongod 真正在监听（不是被其他进程占了） - 在 primary 上抓包：
sudo tcpdump -i any port 27017 -c 5，然后在新节点执行mongosh --host primary-ip:27017—— 若抓不到 SYN 包，说明请求根本没到网络栈 - ufw 用户别只看
status，用sudo ufw status verbose查规则顺序，优先匹配的 deny 规则会拦住初始握手 - 推荐放行写法：
sudo ufw allow from <new-node-ip> to any port 27017 proto tcp</new-node-ip>
真正卡在 STARTUP2 的节点，往往连第一条 oplog 拉取请求都没发出去。与其调优带宽或缓存，不如先确保它能“说上话”——磁盘、oplog、syncSource、端口，四者缺一不可。任何一项不满足，它都不会进入后续阶段。
