Chained Replication（级联复制）是MongoDB早期允许Secondary从其他Secondary同步数据的机制，但自3.2版起默认禁用、4.4版彻底移除；它非但不能有效减轻主节点压力，反而增加延迟、故障风险和运维复杂度；现代替代方案应聚焦读写分离、专用同步节点、oplog优化及批量写入控制。
Chained Replication 是什么，它真能减主节点压力？
不能。MongoDB 的 chained replication（级联复制）在 4.4 版本起已被**完全移除**，且自 3.2 起就默认禁用、不推荐启用。它不是“多级联复制”的实用方案，而是历史遗留机制，曾允许 Secondary 节点从另一个 Secondary 拉取 oplog，而非全部直连 Primary。
但现实问题是：启用它反而增加同步延迟和故障面——比如中间节点宕机，下游节点会卡住；oplog 截断风险更高；监控链路更难定位。官方早在 replSetGetStatus 输出中就不再显示 syncFromHost 字段，rs.conf() 里也剔除了 chainingAllowed: true 配置项。
为什么你看到的文档还在提 chained replication？
那些内容基本来自 2016–2019 年的旧资料，当时 MongoDB 还支持手动设置 rs.syncFrom("secondary-host:port")。但现在：
-
rs.syncFrom()命令在 4.2+ 已被废弃，执行会报CommandNotFound -
mongod启动参数或配置文件中指定chainingAllowed: true会被忽略，日志里出现WARNING: chainingAllowed is deprecated - 即使强行降级到 3.6 并启用，也无法保证稳定——Secondary 之间网络波动会导致 oplog 回退、重同步，主节点仍需承担初始全量同步（initial sync）压力
真正能降低主节点复制压力的替代方案
别试图恢复级联，直接用现代 MongoDB 原生支持的方式：
-
调整读写分离策略：客户端用
readPreference=secondaryPreferred把读流量导到 Secondary，减少主节点连接数和 CPU 占用 -
限制从节点同步频率：Secondary 默认每 2 秒拉一次 oplog；可通过
rs.reconfig()设置members[n].priority=0+members[n].hidden=true创建专用同步节点（不对外提供读服务），再用heartbeatIntervalMillis适当放宽心跳间隔（不建议低于 5000ms） -
优化 oplog 大小：主节点上
oplogSizeMB过小会导致频繁截断，迫使从节点反复做 initial sync；建议按日均写入量 × 24 小时预估，最低不小于 1GB -
避免大文档/大批量写入集中爆发：这类操作会瞬间撑满 oplog 缓冲区，拖慢所有从节点同步速度；改用分批 +
bulkWrite()控制节奏
一个容易被忽略的性能陷阱
很多人以为加更多 Secondary 就能线性分摊主节点压力，但实际：
每个新 Secondary 在 initial sync 阶段都会对主节点发起全量快照（db.fsyncLock() 或 storage.wiredTiger.engineConfig.journalCompressor 相关锁竞争），并持续占用主节点一个连接和磁盘 I/O 带宽。3 个以上从节点共存时，务必确认主节点的 net.maxIncomingConnections 和磁盘吞吐是否足够——否则不是减压，是压垮。
