MongoDB 4.2+已默认启用基于块的流式并行复制，无parallelReplication参数；复制延迟主因是磁盘I/O、网络吞吐或从节点配置不足，需重点监控oplog缓冲队列、磁盘利用率及网络重传率。
副本集在大批量写入时出现复制延迟，不是靠“开启并行复制机制”就能解决的——MongoDB 4.2 及之后版本默认已启用基于块的流式复制（streaming replication），它本身已是并行处理 oplog 的；真正卡住延迟的，通常是磁盘 I/O、网络吞吐或从节点配置不足。
为什么 rs.conf() 里找不到 parallelReplication 相关参数
MongoDB 4.2+ 已移除 parallelReplication 配置项（该选项在 3.4–4.0 中存在但已被废弃）。当前复制引擎自动将 oplog 按逻辑时间戳分块，并发拉取和应用多个块，无需手动开关。如果你在文档或旧教程里看到这个参数，说明内容已过期。
- 4.2 起使用的是
WiredTiger引擎 +oplog增量块同步协议，底层已支持多线程 apply -
rs.conf()输出中不再包含parallelReplication字段，强行添加会报错unrecognized field - 真正影响并行度的是
wiredTiger.cacheSizeGB和storage.journal.enabled等底层配置
复制延迟高时该查哪些关键指标
不要只盯着 rs.status().members[n].optimeDate 看时间差，要结合实时负载判断瓶颈在哪：
- 用
db.serverStatus().metrics.repl.buffer.count查 oplog 缓冲队列长度：持续 >1000 表示从节点拉取跟不上 - 用
db.currentOp({secs_running: {$gt: 5}})看从节点上是否有长时间运行的 apply 操作（常见于大文档更新或索引重建） - 检查
iostat -x 1中从节点的%util和await：若磁盘长期满载，storage.wiredTiger.engineConfig.cacheSizeGB设置过小或日志刷盘太慢是主因 -
netstat -s | grep -i "retransmit"查重传率：>2% 说明网络丢包严重，链路层已拖累复制流
批量写入场景下真正有效的调优动作
重点不在“开启并行”，而在让复制流不被阻塞、不被挤压：
- 主节点写入时避免单条超大文档（>16MB）或批量插入未分片的巨型数组——这会导致单个 oplog 条目过大，从节点无法并发拆解
- 从节点务必关闭
journal（storage.journal.enabled: false）：journal 是为崩溃恢复设计的，复制场景下它反而成为 I/O 瓶颈 - 确保所有节点
wiredTiger.cacheSizeGB≥ 数据集热数据大小的 1.5 倍；否则 apply 过程频繁换页，延迟飙升 - 如需容忍短时延迟，可对读操作显式指定
readConcern: "available"，跳过等待 majority 确认，避免读阻塞写
延迟节点（delayed secondary）不能缓解写入压力，它只是把 oplog 应用人为延后；真正扛住大批量写入的，永远是主从节点的 I/O 能力匹配和 oplog 分块粒度合理性。别被“并行”字眼带偏——MongoDB 的复制早已不是单线程串行 apply 的年代了。
