初始同步流量暴增的根本原因是oplog全量拉取未启用网络压缩；需启用enableMajorityReadConcern并配置compressors，或改用mongodump+rsync物理备份方案。
初始化同步时流量暴增，根本原因是 oplog 全量拉取未压缩
默认情况下，MongoDB 副本集新节点执行 initial sync 时，会从源节点完整拷贝所有数据文件（collection data）+ 重放一段 oplog（通常约 300MB）。整个过程不启用网络层压缩，哪怕你启用了 net.compression.compressors，它也只对常规查询/写入生效，对初始同步无效。
这意味着：100GB 数据集在低带宽（如 2Mbps）下可能同步数天，且期间无法降级为 secondary —— 它卡在 STARTUP2 状态，持续拉取，还可能因超时失败回退到 RECOVERING。
必须用 replSetReconfig 启用 enableMajorityReadConcern: true 并配合 compressors
很多人误以为只要在 mongod.conf 里配了 net.compression.compressors: [zlib] 就能压缩初始同步，其实不行。真正起效的路径是：
- 确保副本集已启用读关注 majority（否则压缩协商失败）：
rs.reconfig({ _id: "rs0", members: [...], enableMajorityReadConcern: true }, { force: true }) - 所有节点
mongod启动时必须带--networkMessageCompressors=zlib（或配置文件中net.compression.compressors: [zlib]），且版本 ≥ 4.2 - 重启全部节点（顺序：先 secondary，再 arbiter，最后 primary），否则新 compressor 不参与握手
注意：zlib 比 snappy 压缩率高 30–50%，但 CPU 开销略大；在树莓派或低配 VPS 上建议用 snappy；zstd 要 MongoDB 4.4+ 且客户端也支持，否则 handshake 直接失败。
同步前手动导出 + 压缩 + rsync 是更可控的替代方案
当带宽低于 5Mbps 或数据量 >50GB 时，硬等 initial sync 风险太高。更稳妥的做法是跳过自动同步，改用物理备份方式：
- 在 primary 上停写（或使用
db.fsyncLock()锁库，注意会阻塞所有写入） - 用
mongodump --gzip --archive=backup.archive导出（--gzip是关键，比默认快照复制小 60%+） - 把
backup.archive用rsync -z --partial推到新节点（断点续传 + 传输层压缩） - 在新节点运行
mongorestore --archive=backup.archive --drop，再启动 mongod 加入副本集
这个流程绕过了 oplog 重放瓶颈，实际传输量常不到原数据的 1/3，且可预估耗时。唯一代价是 primary 短暂只读（fsyncLock 通常
监控同步进度别只看 rs.status().members[n].stateStr
状态显示 SYNCING 并不等于“正在有效传输”。低带宽下容易卡在 APPLYING_OPLOG 阶段，因为 oplog 回放速度跟不上拉取速度，导致内存积压、OOM 或连接中断。
真正要盯的指标是：
-
db.getSiblingDB("local").oplog.rs.stats().sizeOnDisk—— 看本地 oplog 文件是否持续增长（说明还在拉） -
netstat -tnp | grep :27017 | wc -l—— 连接数骤降可能意味着同步线程崩溃 - 源节点日志里搜
repl writer worker和oplog fetcher的 last timestamp 差值，超过 10 分钟就危险
如果发现 oplog lag 持续扩大，立刻停止同步，改用 mongodump 方案——强行等下去只会触发自动 rollback 或数据不一致。
压缩选项本身不解决带宽瓶颈，它只是让有限带宽“挤出更多数据”。真正决定成败的是同步阶段的选择权：是信自动机制，还是自己掌控节奏。
