今天大概研究下wiredtiger引擎，mongo从3.0开始引入，主要为了解决吃内存多，占用大量磁盘空间的问题，其实即使用了wt引擎，在性能上还是比tokuft要差，但是tokuft 在功能上代码迭代的太慢，退而求其次大家还是用了mongo，首先3.0的时候默认还是mmapv1 引擎，所以需要重新指定wt引擎，从3.2版本后就是默认了wt了，我用的现在是3.4 主要是配置上的优化，看了好多人的写的东西，都特么是抄的，我写个官方文档上的吧，以此记录
storage.wiredTiger Options storage: wiredTiger: engineConfig: cacheSizeGB: <number> journalCompressor: <string> directoryForIndexes: <boolean> collectionConfig: blockCompressor: <string> indexConfig: prefixCompression: <boolean>
这个是官方的，一下是我自己的
storage: dbPath: /var/lib/mongo journal: enabled: true # engine: # mmapv1: # wiredTiger: wiredTiger: engineConfig: cacheSizeGB: 0.25 ###这里Size是WT本身的Cache大小并不代表Mongod使用的内存， ###默认是Max(1G，内存的1/2)，这里尽可能给多一些吧，尽量把热数据都可以Cache住， ###保证Dirty 不要超过1%，当然这个跟自己的业务、读写查询快慢有关， ###另外它Cache的单位是Page而不是Document。 journalCompressor: snappy ##单独为Journal Log指定压缩方式，默认snappy，支持"none、snappy、zlib"， ##一般情况下不需要用zlib，虽然压缩率较大，但cpu的占用率也高。 directoryForIndexes: true ## Index文件和数据文件分离，索引一个目录，数据一个目录。 collectionConfig: blockCompressor: zlib ####数据库中Collection的压缩方式，默认是snappy，同样支持"none、snappy、zlib""， ####一般snappy足够，snappy cpu使用率较低，压缩率不是非常高，但可以满足一般业务需求， ####zlib是压缩率最高的，cpu使用率也较高，如果cpu资源充裕，就为了降低磁盘空间可以选择zlib。 indexConfig: prefixCompression: true ###是否开启索引的前缀压缩，这里影响所有DB的索引。它会一次存储所有前缀一样的索引， ###减少内存、磁盘IO的消耗，默认开启。
官方原文：
Values can range from 256MB to 10TB and can be a float. In addition, the default value has also changed.
Starting in 3.4, the WiredTiger internal cache, by default, will use the larger of either:
- 50% of RAM minus 1 GB, or
- 256 MB.
Avoid increasing the WiredTiger internal cache size above its default value.
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.
Via the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes. Data in the filesystem cache is compressed.
由此可以看出，在内存足够大的情况下，还是要以提高cpu性能为主，zlib虽然是最高压缩，但也最吃cpu另外，在存储引擎切换的时候，先从second开始，进入服务器，db.shutdownServer(),把服务器关掉，然后清空所有数据，然后配置wt引擎，然后在挂载回去，进行重新同步
官方的原文：http://docs.mongoing.com/manual-zh/tutorial/change-replica-set-wiredtiger.html
步骤
这个步骤将复制集中 secondary 的数据完全移除, 然后使用 WiredTiger 存储引擎重启 mongod, 利用:doc:`初始化同步 完成数据同步.
在升级复制集中的成员存储引擎时, 首先升级 secondary 成员. 然后将 primary 降级为从节点, 之后升级降级为从节点的成员.
1
Shut down the secondary member.
In the mongo shell, shut down the secondary mongod instance you wish to upgrade.
db.shutdownServer()
2
Prepare a data directory for the new mongod running with WiredTiger.
Prepare a data directory for the new mongod instance that will run with the WiredTiger storage engine.mongod must have read and write permissions for this directory. You can either delete the contents of the stopped secondary member’s current data directory or create a new directory entirely.
mongod with WiredTiger will not start with data files created with a different storage engine.
3
Start mongod with WiredTiger.
Start mongod, specifying wiredTiger as the --storageEngine and the prepared data directory for WiredTiger as the --dbpath. Specify additional options as appropriate for this replica set member.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName>
Since no data exists in the --dbpath, the mongod will perform an initial sync. The length of the initial sync process depends on the size of the database and network connection between members of the replica set.
You can also specify the options in a configuration file. To specify the storage engine, use thestorage.engine setting.
4
Repeat the procedure for other replica set secondaries you wish to upgrade.
Perform this procedure again for the rest of the secondary members of the replica set you wish to use the WiredTiger storage engine.