oplog写入放大导致磁盘i/o飙升，因oplog过小或写入突增引发频繁滚动重写；需通过db.admincommand({replsetresizeoplog:1,size:20480})扩容至20–50gb，并确保磁盘剩余空间≥新大小×2。
副本集 Oplog 写入放大导致磁盘 I/O 飙升
副本集主节点写入时，除了更新数据文件，还要持续追加 oplog（操作日志），从节点则需不断拉取并重放。若 oplog 太小或写入量突增，会引发频繁的滚动、截断和重写，显著抬高磁盘写 I/O。
- 检查当前大小：
db.getReplicationInfo()，重点关注maxSize和oldestTimestamp - 默认
oplog为可用磁盘空间的 5%，但最小 1GB、最大 50GB —— 对写入密集型业务（如每秒数百次写）极易不够用 - 扩容方法：在主节点执行
rs.stepDown()触发选举后，在新主上运行db.adminCommand({ "replSetResizeOplog": 1, "size": 20480 })（单位 MB），建议设为至少 20–50GB - 注意：该命令仅支持 WiredTiger 引擎，且需确保磁盘剩余空间 ≥ 新 oplog 大小 × 2（因重写过程需临时空间）
Secondary 节点同步压力过大引发 I/O 拥塞
从节点同步不是简单复制，而是读取 oplog → 解析操作 → 执行写入 → 更新自身索引，整个链路对磁盘随机 I/O 压力极大。尤其当主节点批量写入或构建索引时，从节点容易“追不上”并持续刷盘。
- 确认同步延迟：
rs.printSlaveInfo()或查看secondaryDelaySecs配置是否被误设 - 避免在主节点执行耗时操作（如
createIndex）时让所有从节点同时参与 —— 可临时将部分从节点设为priority: 0和hidden: true，等索引建完再恢复 - 从节点启用
storage.journal.enabled: false（仅限非仲裁节点且能接受少量数据丢失风险），可大幅降低 WAL 日志写 I/O；但务必确保其不承担写流量 - 检查
syncSourceHost是否指向网络延迟高或 I/O 已饱和的节点，必要时手动指定更健康的同步源：rs.syncFrom("other-secondary:27017")
WiredTiger 缓存与磁盘争抢加剧 I/O 波动
副本集每个节点都独立运行 WiredTiger，若缓存配置不合理，会导致大量冷数据反复进出磁盘，I/O 表现为周期性尖峰而非稳定负载。
- 缓存不是越大越好：
storage.wiredTiger.engineConfig.cacheSizeGB默认按min(50%×内存−1GB, 256MB)计算，但在多节点共用物理机时极易超配 - 查实际使用：
db.serverStatus().wiredTiger.cache["bytes currently in the cache"] / 1024 / 1024 / 1024，若长期 >90% max，说明工作集溢出，必须扩容或优化查询 - 容器或共享主机部署时，必须显式限制缓存，例如 16GB 内存的宿主机跑 2 个副本节点，每个应设为
cacheSizeGB: 4，而非默认约 7GB - 关闭透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则 WiredTiger 的细粒度内存分配会触发内核抖动，间接恶化 I/O 响应
索引与数据目录未隔离，读写互相干扰
WiredTiger 默认把集合数据和索引混存在同一目录，副本集同步时既读 oplog 又写数据又更新索引，多个随机 I/O 流在单盘上竞争寻道，IOPS 利用率虚高但吞吐低下。
- 启用索引分离：
storage.wiredTiger.engineConfig.directoryForIndexes: true，重启后索引将存于dbpath/indexes/ - 若有多块 SSD/NVMe 盘，可进一步把
dbpath和indexes分别挂载到不同设备（如/data/mongo和/data/mongo_indexes） - 不要在单盘上做 RAID 0 —— 条带化对副本集无意义，反而增加故障域；RAID 10 是多盘场景下更稳妥的选择
- 注意：开启
directoryForIndexes后，mongodump不会自动备份索引目录，需额外tar -cf indexes.tar /path/to/indexes
oplog 大小、同步节奏、缓存水位、目录布局，四者相互牵制。最容易被忽略的是：从节点的 journal 在同步高压下其实成了性能拖累，而很多人只盯着主节点调优。
