全量同步会拖垮主库是因为主节点需同时处理数据压缩传输、日常写入和oplog生成，导致磁盘i/o瓶颈、网络带宽打满及wiredtiger缓存抖动，引发响应延迟与选举风险。
为什么全量同步会拖垮主库？
全量同步（initial sync）本质是主节点临时变成“文件服务器”：它要压缩整个数据目录、逐块传输，同时还得维持日常写入和 oplog 生成。这三件事叠加，极易触发磁盘 I/O 瓶颈、网络带宽打满、WiredTiger cache 剧烈抖动——表现就是主节点响应变慢、写入延迟飙升、甚至触发 election。
- 主节点在 initial sync 中不参与数据压缩，但所有 chunk 请求都由它响应，
netstat -an | grep :27017可见大量ESTABLISHED连接指向新节点 - 传输过程不走 oplog，而是直接读取
dbPath下的数据文件（.wt），对磁盘随机读压力极大 - 若主节点本身
wiredTiger.cacheSizeGB设置偏小（如默认 1GB），大量读取会挤占写缓存，加剧 stall
如何让新节点不找 PRIMARY 做初始同步？
副本集默认允许 Secondary 自主选择 sync source，只要该节点状态正常、oplog 足够新、且 ping 延迟更低。关键不是“禁止连主”，而是“引导它连谁”。
- 启动新节点时，用
--syncSourceHost参数指定一个负载低、网络近的 Secondary，例如：mongod --replSet rs0 --syncSourceHost 10.0.0.2:27017 - 或在配置文件中设置：
initialSyncSourceReadPreference: "nearest"（MongoDB 5.0+），让节点自动选 ping 最短的可用源 - 确保被选为 sync source 的节点
rs.status().members[n].stateStr是SECONDARY，且optimeDate落后主节点不超过 5 分钟（否则可能触发 fallback 到 PRIMARY） - 避免把 Priority 0 节点（仅备份用途）设为 sync source，它虽能同步，但默认不参与选举投票，部分版本对其 sync source 能力有限制
能否跳过全量同步，直接追 oplog？
可以，但前提是新节点的 local.oplog.rs 存在、且覆盖范围包含主节点当前最小 oplog 时间戳。这叫“可恢复的初始同步”（resumable initial sync），不是 magic，而是依赖 oplog 完整性。
- 若旧节点曾运行过，停机前未清空
dbPath，重启后可能自动 resume —— 查rs.status().members[n].stateStr是否为STARTUP2而非RECOVERING - 手动触发需满足：目标节点
local.oplog.rs的firstEventTime≤ PRIMARY 的getReplicationInfo().earliestTime；否则报错could not find base oplog entry - 检查方法：
db.getReplicationInfo()在 PRIMARY 上看 earliestTime，再在目标节点执行db.local.oplog.rs.find().sort({$natural:1}).limit(1)对比时间 - 一旦 oplog 断裂，就只能全量同步——此时与其硬扛，不如先调大 PRIMARY 的 oplog（
db.adminCommand({replSetResizeOplog: 1, size: 20480})），再重试
真正安全的扩容节奏是什么？
别一次性加多个节点，也别在业务高峰做 initial sync。主库压力不是线性增长，而是存在阈值拐点：当并发 sync request > 3–5 个，I/O util 就可能从 60% 跳到 95%+。
- 每次只加 1 个节点，等它稳定进入
SECONDARY状态（rs.status().members[n].health === 1），且optimeDate落后 - 避开凌晨批处理、日终结算、大促流量峰期；观察
mongostat --host PRIMARY的net recv和net send是否持续 > 80MB/s - 如果必须快速上线，优先考虑滚动重建：先下线一个旧 Secondary，清空其
dbPath，再以--syncSourceHost指向另一个 Secondary 启动——避免任何节点直连 PRIMARY
全量同步不是开关，而是资源竞争。真正要控制的不是“要不要同步”，而是“谁来同步、何时同步、同步多少”。oplog 大小、sync source 选择、节点启动参数，这三个点卡住了，主库就不会被拖垮。
