Oplog大小不足是副本集同步慢的首要原因，需通过db.getReplicationInfo()检查并按写入峰值×保留时长（建议24–72小时）扩容，4.4+可在线执行replSetResizeOplog命令。
为什么副本集同步慢，Oplog大小是首要排查点
生产环境 MongoDB 副本集出现同步延迟（optimeDate 落后主节点数分钟甚至小时），80% 以上的情况不是网络或磁盘瓶颈，而是 oplog 太小，导致从节点还没来得及拉取完，旧操作就被覆盖了——从节点被迫进入“追赶模式”（initial sync）或反复断连重试。
Oplog 是固定大小的 capped collection，位于 local.oplog.rs。默认大小取决于 MongoDB 版本和部署方式（如云服务可能设为 1GB），但对写入量大的业务远远不够。
- 查看当前 oplog 大小：
db.getReplicationInfo()
关注maxSizeMB和timeDiffHours（可用时间窗口） - 估算所需大小：按峰值写入速率 × 期望保留小时数（建议至少保留 24 小时 oplog，写入密集场景建议 48–72 小时）
- 注意：不能直接
db.runCommand({captrunc: "local.oplog.rs", ...})修改；必须重建 oplog（需停机或滚动维护）
如何安全扩大 Oplog（4.4+ 支持在线调整）
MongoDB 4.4 起支持 replSetResizeOplog 命令在线扩缩容 oplog，无需重启、无需初始同步，但要求所有节点版本 ≥ 4.4 且启用 featureCompatibilityVersion: "4.4"。
- 在 Primary 上执行：
db.adminCommand({replSetResizeOplog: 1, size: 10240})（单位 MB，例如 10GB） - 命令会自动在后台重建 oplog，期间不影响读写，但会短暂阻塞写入（毫秒级）
- 执行后立即检查：
db.getReplicationInfo()确认maxSizeMB已更新，且timeDiffHours显著增加 - 旧版本（≤ 4.2）必须通过停机方式：关闭 Secondary → 删除
local.oplog.rs→ 启动并等待 initial sync → 再对 Primary 执行相同流程（风险高，慎用）
同步拉取线程数不够？别乱调 numInitialSyncAttempts
很多人看到同步慢就去改 numInitialSyncAttempts 或 syncSourceHost，这是误区。该参数只控制 initial sync 失败后的重试次数，不影响日常 oplog 拉取性能。
真正影响实时同步吞吐的是后台 fetcher 线程行为，由以下隐式机制决定：
- oplog 拉取本身是单线程 per-sync-source（每个源一个 fetcher），无法靠配置“加线程”提速
- 瓶颈常出现在：Secondary 的
applyOps阶段（即回放 oplog）卡住，比如索引构建、大文档更新、WiredTiger cache 不足 - 验证是否 apply 卡顿：观察
db.serverStatus().metrics.repl.apply中的queued和numApplied变化率；同时检查db.currentOp({secs_running: {$gt: 5}})是否有长时间运行的applyOps操作 - 缓解方法：确保
wiredTiger.cacheSizeGB足够（建议 ≥ 总内存的 50%），避免 Secondary 同时做大量读请求挤占 cache
同步慢的隐蔽原因：心跳超时与优先级干扰
同步延迟有时根本不是数据传输问题，而是副本集元数据层面的“失联假象”。典型表现是 rs.status() 中某节点状态频繁在 SECONDARY 和 RECOVERING 之间跳变，lastHeartbeatMessage 提示 could not detect a primary。
- 检查
settings.heartbeatTimeoutSecs（默认 10 秒）：若网络抖动明显，可临时调大至 30，避免误判失联 - 确认没有意外设置
priority: 0或hidden: true的节点被选为 sync source——Secondary 默认从 priority 最高且非 hidden 的节点拉取，若该节点自身也延迟，就会形成“延迟链” - 强制指定同步源（仅调试用）：
rs.syncFrom("primary-hostname:27017")，但切勿长期使用，会破坏自动故障转移逻辑 - 最易忽略的一点：防火墙或安全组未放开
27017的双向心跳端口（不仅是主连从，从也要能反向连主）
Oplog 大小和同步源选择是可快速验证、见效明确的两个杠杆；而 apply 阶段的瓶颈需要结合 cache、锁、慢操作综合判断。线上调参前，务必先用 db.getReplicationInfo() 和 rs.printSlaveReplicationInfo() 定位到底是“没数据可拉”，还是“有数据但拉不动、回放不动”。
