副本集启用zstd压缩需所有成员统一配置：MongoDB≥4.2，mongod.conf中wiredTiger.collectionConfig.blockCompressor设为zstd，逐个重启；不一致会导致同步异常、CPU浪费或启动失败。
副本集里配置数据压缩，和单节点完全一致——WiredTiger 的压缩是存储引擎级行为，不随复制拓扑变化。只要每个成员都使用 WiredTiger（默认），且配置了 blockCompressor，压缩就生效。
如何在 mongod.conf 中为副本集统一启用 zstd 压缩
所有副本集成员必须使用相同配置文件结构，否则可能因压缩不兼容导致同步异常（例如主节点用 zstd 写入，从节点若误配为 none，虽能读但失去空间优势；更严重的是，若从节点版本不支持 zstd，则无法启动）。
- 确认所有成员 MongoDB 版本 ≥ 4.2（
zstd支持始于 4.2）；低于该版本只能选snappy或zlib - 编辑每个成员的
/etc/mongod.conf，在wiredTiger下设置：
storage:
engine: wiredTiger
wiredTiger:
collectionConfig:
blockCompressor: zstd
indexConfig:
prefixCompression: true
-
indexConfig.prefixCompression建议保持true（默认），它独立于块压缩，对索引前缀去重，开销极小且几乎总有益 - 修改后需逐个重启成员：
sudo systemctl restart mongod；不要批量重启，避免副本集失联
为什么不能只在主节点设 zstd，从节点留默认 snappy
可以运行，但会埋下两个隐患：
- 主节点写入的数据块用
zstd压缩，从节点同步时解压再以本地配置（snappy）重新压缩写入磁盘——多一次解压+压缩，徒增 CPU 和 I/O，且无实际收益 - 若未来某次滚动升级中某个从节点临时降级到 4.0，而主节点仍用
zstd，该从节点将无法解析新写入的压缩块，同步卡住并报错：WiredTigerError: unsupported compressor 'zstd' - 监控时容易误判：通过
db.serverStatus().wiredTiger.collectionStats查看各集合压缩算法，会发现主从不一致，增加排查成本
snappy 和 zstd 在副本集中的真实差异点
不是“能不能用”，而是“在哪种负载下谁更稳”：
-
snappy：压缩/解压延迟稳定在 sub-millisecond 级，CPU 占用波动小；适合写入峰值频繁、副本集多数成员为低配 VM 的场景 -
zstd：默认级别（zstd:3）压缩率比snappy高约 35%，但单次压缩耗时高 2–3 倍；若副本集开启读写分离（readPreference=secondary），从节点解压压力会上升，需确认其 CPU 余量 ≥ 40% - 压缩级别可调：可在配置中显式加
compressionLevel: 1（最低）来逼近snappy速度，或设compressionLevel: 6追求更高压缩率（注意：级别 > 9 会显著拖慢写入，不建议在副本集主节点使用）
验证副本集所有成员是否真正启用了 zstd
不能只连主节点查，必须挨个连每个成员（包括隐藏节点、延迟节点）执行：
mongo --host <member-host>:27017 --eval "db.runCommand({serverStatus: 1}).wiredTiger.collectionStats['<any-collection>'].options.blockCompressor"
- 输出必须是
"zstd"，而非空或"snappy" - 若某成员返回
undefined，说明该集合尚未写入数据，或该成员未加载该集合的统计信息；可先插入一条测试文档再查 - 检查
db.stats()中dataSize与storageSize比值：长期运行后，zstd 集合该比值应明显低于 snappy 集合（例如 0.6 vs 0.8），这是最直接的空间证据
副本集压缩配置最易被忽略的，是成员间版本与配置的严格一致性——哪怕一个延迟节点漏配，也会让整套压缩策略在故障切换时失效。
