分片集群复制延迟高本质是secondary被业务读和后台任务抢占cpu、i/o及网络带宽，而非复制本身慢；secondarypreferred会加剧延迟，因其使secondary同时承担业务查询与本shard全部oplog复制双重压力；需用readconcern:"available"隔离通道，并限制maxconcurrentops、关闭冗余日志刷盘。
分片集群复制延迟高，不是“复制慢”，而是 Secondary 被业务读和后台任务抢光了 CPU、I/O 和网络带宽——调大 oplogSize 或换 SSD 只能掩盖症状，解决不了根本问题。
为什么 secondaryPreferred 会让延迟更严重
把读切到 Secondary 看似卸载 Primary，实则让从节点同时扛两件事：服务业务查询（尤其是 aggregate、getMore），还要拉取并重放本 Shard 的全部 oplog。分片集群里每个 Shard 自身就是副本集，Secondary 的复制链路是跨分片写入的聚合结果，压力天然比单副本集高。
- 执行
db.currentOp({secs_running: {$gt: 5}})发现大量未完成读操作阻塞复制线程 -
rs.printSlaveReplicationInfo()显示延迟 >30s，但top看 CPU 不高，iostat却显示await>80ms - 误区：以为
readPreference控制“谁来读”，却忽略了它不控制“读占多少资源”
用 readConcern: "available" 隔离复制通道
MongoDB 4.4+ 提供 readConcern: "available"，让业务读跳过 majority 提交等待，同时不干扰 oplog 应用路径——这是唯一能真正把“业务读”和“复制拉取”在逻辑上分开的机制。
- 必须在 mongos 层显式带上：连接字符串加
&readConcernLevel=available，或代码中显式指定readConcern: { level: "available" } - 不能依赖驱动默认行为：
Node.js Driver默认不设readConcern；Java Driver需手动构建ReadConcern.AVAILABLE - 注意兼容性：老版本 MongoDB 会报
Unsupported read concern level
限制 Secondary 并发读，给复制留出资源余量
默认 maxConcurrentOps=512 对复制太激进。需主动压低，确保复制线程能稳定获得 CPU 时间片和磁盘 I/O 带宽。
- 执行
db.runCommand({ setParameter: 1, maxConcurrentOps: 64 })（根据负载调至 32–128 区间） - 关闭冗余日志刷盘：
db.runCommand({ setParameter: 1, logLevel: { "storage.wiredTiger.recovery": 0 } })，避免日志抢占 I/O - 检查是否生效：连上 Secondary 执行
db.runCommand({ getCmdLineOpts: 1 })，确认parsed.setParameter包含对应设置
别只盯 optimeDate，看 lastHeartbeatMessage 和 syncSourceHost
replSetGetStatus 里真正暴露带宽挤占的是心跳状态组合，而非单纯时间差：
- 如果
lastHeartbeatMessage长期为"syncing to: xxx"但延迟持续上涨，说明syncSource正被其他请求拖慢 - 重点对比
syncSourceHost和当前节点的lastHeartbeat时间差，若差值 >5s 且波动大，基本可判定网络或 syncSource 负载已饱和 - 此时改
heartbeatTimeoutSecs没用，反而可能引发脑裂；真正该调的是heartbeatIntervalMillis（默认 2000，稳定链路可试 1000）
最易被忽略的点：延迟高时第一反应常是“加大硬件资源”或“调大 oplog”，但实际瓶颈往往卡在 mongos 路由层或 Secondary 的资源争抢上——尤其当 readPreference 和 readConcern 搭配不当，或者没压住并发读上限时，再多 SSD 也救不回同步链路。
