mongoreplay录制时忽略admin命令、连接握手、直连分片路由、$where/mapReduce等JS操作；重放需用--connections、--no-keepalive、DNS轮询绕过粘性；写入延迟突增多因config server元数据锁竞争；波动需结合--replay-time、索引一致性及mongotop/profiling分析。
用 mongoreplay 录制真实流量时，哪些操作会被忽略？
mongoreplay 默认只捕获 mongod 的 wire protocol 流量，但以下操作不会被记录：
-
admin数据库下的命令（如db.runCommand({ replSetGetStatus: 1 })）——除非显式开启--include-admin - 连接建立/断开、心跳包、
isMaster探测等底层握手行为 - 使用
mongos连接时，若客户端直连分片而非经由mongos，则路由逻辑丢失，重放时可能打到错误分片 - 带
$where、mapReduce或自定义 JavaScript 的操作，在重放时默认被跳过（需加--js参数启用）
实际录制前建议先在测试环境跑通一次完整业务链路，并用 mongostat --host <mongos-addr> 确认流量确实经过 mongos，否则重放结果无法反映分片集群的真实路由与负载分布。
重放时如何让 mongoreplay 均匀打到所有分片？
默认情况下，mongoreplay 会复现原始连接的 IP 和端口，如果原始流量来自单台应用服务器，重放时所有请求仍会发往同一个 mongos 实例，进而可能因连接复用、会话粘性或 mongos 内部缓存导致流量倾斜。
解决方法是强制打散连接并绕过本地路由缓存：
- 用
--connections <n>启动多个并发连接（例如--connections 16），每个连接独立建链 - 添加
--no-keepalive，避免 TCP 复用掩盖连接数不足的问题 - 指向一个
mongos的 DNS 名称（而非 IP），并确保该名称解析为多个mongos实例（配合客户端负载均衡，如mongodb://mongos-a,mongos-b/?localThresholdMS=15） - 禁用
mongoreplay的 replay-time 模拟（去掉--replay-time），否则短时间密集重放可能触发mongos的慢查询限流，掩盖分片层瓶颈
压测中发现写入延迟突增，但 CPU 和磁盘 I/O 都不高，问题通常出在哪？
这是分片集群典型的“元数据锁竞争”现象：当大量写入命中同一 chunk 的边界（尤其带 _id 或时间字段做片键），mongos 需频繁向 config server 查询 chunk 分布，而 config server 使用 WiredTiger 引擎且不支持分片，容易成为单点瓶颈。
快速验证方式：
- 在
config server上执行db.currentOp({ secs_running: { $gt: 1 } })，观察是否有大量阻塞在find或updateonchunks集合 - 检查
sh.status()输出中是否存在大量balancer迁移任务堆积（moveChunk正在运行中） - 确认片键是否导致写入热点：比如用
timestamp作为升序片键，所有新文档都写入最后一个 chunk
临时缓解可关闭均衡器（sh.stopBalancer()），但根本解法是重新评估片键，优先选高基数、写入离散、支持范围查询的字段组合（如 { userId: 1, timestamp: -1 }）。
mongoreplay 重放结果里 read/write ops/s 波动极大，怎么判断是否真实？
波动本身未必异常，关键看是否与原始流量特征一致。原始录制文件中的操作时间戳决定了重放节奏，但以下因素会导致失真：
- 原始流量含大量空闲等待（如应用层重试间隔、用户思考时间），而
mongoreplay默认压缩这些间隙；需加--replay-time保持原始时序 - 重放目标集群的索引缺失或不匹配（例如线上有复合索引，压测集群只有单字段索引），导致部分查询从
IXSCAN退化为COLLSCAN，延迟飙升且不可预测 -
mongoreplay不重放写操作的应答延迟，只按发送顺序发包；若网络 RTT 变化大（如压测机与集群不在同可用区），mongostat显示的netIn/netOut会失真
建议用 mongotop --host <mongos-addr> 对比重放前后各数据库/集合的读写毫秒占比，再结合 db.setProfilingLevel(2) 抓取慢操作样本——真正的问题往往藏在 top 3 耗时集合的执行计划里，而不是总 QPS 数字上。
