mongodb3.0更改压缩方式操作步骤

近几日，公司某业务mongodb机器(版本3.0.5),频繁出现oom故障，经过判断是用了WiredTiger引擎zlib压缩导致的故障。

ps：此业务平均3000+tps，高峰期1万＋tps，zlib完全扛不住这样高的并发，后来改成不压缩却发现每天会产生200G左右的数据，业务方面需要保存一月的数据，200G＊30=6T，现有机器没有这么大的磁盘，在经过测试对比后决定使用折中的snappy压缩方式，具体的测试方法有时间再另做描述。

下为具体的操作步骤

1、现有的情况是mongodb复制集改成不压缩已经一周多了，产生了1.5t的数据，而设置的过期时间是一个月，直接改成snappy的话仅剩的300G磁盘是不够支撑剩余的3周的，没办法，只能先重做其中的一台从库，删除数据，设置好压缩格式（snappy＋索引前缀压缩）后，选择一个低峰的时间进行同步。

注意：

  高并发的机器直接做主从数据同步一定要注意，我在同步期间业务耗时直接涨了10倍以上，好在并不是核心业务，所以还能接受。

  同步之前注意观察下当前主库的oplog时间，做好预估，别同步玩发现oplog已经超过了开始同步的时间就傻眼了，查看oplog时间命令：db.printReplicationInfo(),如何修改oplog大小请点击mongodb修改oplog大小 ，这里要注意oplog的数据是直接占用内存的，不能设置的太大。

  还有个要注意的地方是需要将同步的机器hiden设置成true

2、大约15个小时后，同步完成，一周的数据量在snappy压缩格式下约350G (不压缩是1.5t，zlib压缩是150G)。有了这台机器1，另外台从库2就可以不需做全量同步，可以直接全量copy机器1的数据到机器2，千兆网卡下350G二十分钟便搞定。

注意：拷贝过程中机器1需关闭mongo，拷贝完成后，修改机器2的配置文件指向新的数据库，更改压缩方式，启动机器1和2的mongo，待optimeDate时间追上主库便ok

3、切换主库到机器1或者2，将原主库机器3按照第2步的方法同步数据，全部同步完成后，整个切换过程完成。