mongodb配置文件解析

样例（YAML格式）：
systemLog:

destination: file #日志的目标，可指定为file或者syslog。指定为file时也必须指定systemLog.path。如果不指定就是标准输出。path: "/data/mongodb/log/mongod.log"logAppend: true #如果指定为true，那么重新启动mongo后，日志会在原来的文件中追加。如果指定为false，则会覆盖之前的日志文件。logRotate: rename #为了防止日志文件过大，此选项可指定rename和reopen。                  rename使用时间戳重新命名旧的日志文件，新日志发送到新建的日志文件中。                  reopen是关闭并重新打开日志文件。是典型的Linux/Unix的日志切换行为.必须手动重命名日志文件。timeStampFormat: ctime #默认：iso8601-local 时间戳格式，可指定为ctime，iso8601-utc,iso8601-local.traceAllExceptions： #解释：为调试打印多余的信息，这些多余的信息有利于我们排除故障。quiet: true #生成环境下不建议使用，不利于排查问题

PS：

component:   accessControl:       verbosity: <int>

mongo把日志分为了多个组件，我们可以分别指定这些组件的冗余水平。

组件 说明 举例accessControl 访问控制日志 比如验证command 命令日志 比如调用count方法control 控制日志 比如初始化control 控制日志 比如初始化ftd 统计和状态日志 GEO JSON结构 index 索引日志 比如创建索引network 网络日志 比如接收到连接query 查询日志 比如findreplication 副本日志 比如同步心跳sharding 分片日志 比如启动mongosstorage 存储日志 比如执行fsync命令。有一个子模块journal，如果journal不指定则默认是storage水平。write 写日志 比如update

storage:

dbPath: "/data/mongodb/data/"indexBuildRetry：true #当构建索引时mongod意外关闭，那么再次启动是否重新构建索引；索引构建失败，mongod重启后将会删除尚未完成的索引，但是否重建由此参数决定。默认值为true。

journal:

enabled: true #是否开启journal日志持久存储（redo），journal日志用来数据恢复，是mongod最基础的特性，通常用于故障恢复。64位系统默认为true，32位默认为false，建议开启，仅对mongod进程有效。commitIntervalMs: 100 #The maximum amount of time in milliseconds that the mongod process allows between journal operations. mongod进程提交journal日志的时间间隔。较低的值增加了juornal的耐久性，以牺牲性能为代价，在wiredtiger引擎上，默认的日志提交间隔为100毫秒。建议不要修改。【如果单块设备提供日志和数据文件，默认的日记提交时间间隔为100毫秒，如果不同的块设备提供的日志和数据文件，默认的日记提交的时间间隔为30毫秒。】

directoryPerDB: true #是否将不同DB的数据存储在不同的目录中，dbPath的子目录，目录名为db的名称。对已经存储数据的mongod修改此值，需要首先使用mongodump指令将数据导出，然后关闭mongod，再修改此值和指定新的dbPath，然后使用mongorestore指令重新导入数据。（即导出数据，并使用mongorestore将数据重新写入mongod的新目录中）。对于replica set架构模式，只需要在每个secondary依次操作：关闭secondary，然后配置新的dbPath，然后启动即可（会执行初始化sync，从primary中将数据去完全同步到本地）。最后操作primary。此参数仅对mongod进程有效，默认值为false。
syncPeriodSecs: 60 #mongod使用fsync操作将数据flush到磁盘的时间间隔，默认值为60（单位：秒），强烈建议不要修改此值；mongod将变更的数据写入journal后再写入内存，并间歇性的将内存数据flush到磁盘中，即延迟写入磁盘，有效提升磁盘效率。此指令不影响journal存储，仅对mongod有效。
engine: wiredTiger #从mongodb3.2开始，官方已经开始默认使用wiredTiger存储引擎，在3.2之前默认使用mmapv1存储引擎。
mongodb数据库的存储引擎，可用的值包括：mmapv1：指定mmapv1存储引擎（3.2之前默认使用）、wiredTiger：指定wiredTiger存储引擎（3.2开始默认使用）、inMemory：指定内存存储引擎（在3.2还是bate版本）。
PS：新旧版本存储引擎比较：

对比：http://learn-mongodb.readthedocs.io/storage-engine/wiredtiger-vs-mmapv1/
wiredTiger:

engineConfig:    cacheSizeGB: 40 #wiredtiger将使用所有数据的最大缓存大小，wiredTiger缓存工作集（working set）数据的内存大小，单位：GB，此值决定了wiredTiger与mmapv1的内存模型不同，它可以限制mongod对内存的使用量，而mmapv1则不能（依赖于系统级的mmap）。默认情况下，cacheSizeGB的值为假定当前节点只部署一个mongod实例，在MongoDB 3，默认情况下，wiredtiger缓存，使用1 GB或安装的物理内存的一半，以较大者为准。如果当前节点部署了多个mongod进程，那么需要合理配置此值。如果mongod部署在虚拟容器中（比如，lxc，cgroups，Docker）等，它将不能使用整个系统的物理内存，则需要适当调整此值。默认值为物理内存的一半。    journalCompressor: snappy #journal日志的压缩算法，默认为“snappy”，可选值为“none”、“snappy”、“zlib”。    directoryForIndexes： false #是否将索引和collections数据分别存储在dbPath单独的目录中。即index数据保存“index”子目录，collections数据保存在“collection”子目录。默认值为false，仅对mongod有效。 

collectionConfig：

    blockCompressor： sanappy #collection数据压缩算法，可选值“none”、“snappy”、“zlib”。开发者在创建collection时可以指定值，以覆盖此配置项。如果mongod中已经存在数据，修改此值不会带来问题，旧数据仍然使用原来的算法解压，新数据文件将会采用新的解压缩算法。

indexConfig:

    prefixCompression: true #是否对索引数据使用“前缀压缩”（prefix compression，一种算法）。前缀压缩，对那些经过排序的值存储，有很大帮助，可以有效的减少索引数据的内存使用量。默认值为true。

processManagement:

    fork: true #是否以fork模式运行mongod/mongos进程，默认情况下，mongod/mongos不作为守护进程运行，默认为true。    pidFilePath: /tmp/mongod.pid

security:

    keyFile: /data/mongodb/keyfile     authorization: "enabled"

net:

   bindIp: 0.0.0.0 #mongod/monogs进程绑定的IP，application通过此IP、port建立链接。可以绑定在任意网卡接口上，如果你的mongos/mongod只需要内网访问，可以绑定在内网IP(例如：192.168.1.100)，如果需要外网访问，那么则绑定外网IP，如果此值为“0.0.0.0”，则绑定到所有接口即内网、外网IP均可以访问。（不建议）可以绑定都多个ip上，ip地址之间用“,”分割。   port: 27017   maxIncomingConnections: 65536 #mongod/mongos进程允许的最大连接数，如果此值超过操作系统配置的连接数阀值，将不会生效(ulimit)；默认值为65536。通常客户端将会使用连接池机制，可以有效的控制每个客户端的链接个数。   wire Check: true #当客户端写入数据时，mongos/mongod是否检测数据的有效性(BSON)，如果数据格式不良，此insert、update操作将会被拒绝；默认值为true。对于高程度的子文档嵌套的对象，net.wire check对性能有较小的影响。   ipv6: false #是否支持mongos/mongod多个实例之间使用IPV6网络，默认值为false。此值需要在整个cluster中保持一致。   unixDomainSocket:  #指定sock文件的存放路径，默认是放在/tmp       enabled: true       pathPrefix: /data/mongo/data

replication:

  oplogSizeMB: 10240 #replication操作日志的最大尺寸，单位：MB。mongod进程根据磁盘最大可用空间来创建oplog，比如64位系统，oplog为磁盘可用空间的5%，一旦mongod创建了oplog文件，此后再次修改oplogSizeMB将不会生效。此值不要设置的太小， 应该足以保存24小时的操作日志，以保证secondary有充足的维护时间；如果太小，secondary将不能通过oplog来同步数据，只能全量同步。此值仅对mongod有效。  replSetName: "repl_test" #“复制集”的名称，复制集中的所有mongd实例都必须有相同的名字，sharding分布式下，不同的sharding应该使用不同的replSetName。仅对mongod有效。  secondaryIndexPrefetch: "all" #默认值all，复制集中的secondary，从oplog中运用变更操作之前，将会先把索引加载到内存中，默认情况下，secondaries首先将操作相关的索引加载到内存，然后再根据oplog应用操作。可选值：  1）none：secondaries不将索引数据加载到内存。  2）all：sencondaries将此操作有关的索引数据加载到内存。  3）_id_only：只加载_id索引。

operationProfiling:

  slowOpThresholdMs: 100 #数据库profiler判定一个操作是“慢查询”的时间阀值，单位毫秒；mongod将会把慢查询记录到日志中，即使profiler被关闭。当profiler开启时，慢查询记录还会被写入“system.profile”这个系统级的collection中。请参看mongod profiler相关文档。默认值为100，此值只对mongod进程有效。  mode: slowOp #数据库profiler级别，操作的性能信息将会被写入日志文件中，可选值： 1）off：关闭profiling。 2）slowOp：on，只包含慢操作日志。 3）all：on，记录所有操作。

数据库profiling会影响性能，建议只在性能调试阶段开启。此参数仅对mongod有效。
sharding:

clusterRole: #在sharding集群中，此mongod实例的角色，可选值：

1）configsvr：此实例为config server，此实例默认侦听27019端口
2）shardsvr：此实例为sharding（分片），侦听27018端口
此配置仅对mongod有效。通常config server和sharding server需要使用各自的配置文件。

archiveMovedChunks: #当chunks因为“负载平衡”而迁移到其他节点时，mongod是否将这些chunks归档，并保存在dbPath下“moveChunk”目录下，mongod不会删除moveChunk下的文件。默认为true。

auditLog:

destination #开启审计，需指定审计记录的输出方式，有以下值可选syslog、console、file。format #目标文件的输出文件格式，有如下值:    JSON: 输出的审计事件的JSON格式文件，–auditpath指定。    BSON: 输出的审计事件的JSON格式文件，–auditpath指定。path #如果审计时间输入为文件，那么这里就需要指定文件的完整路径及文件名。filter #过滤器，可以限制审计系统记录的操作类型，该选项需要一个表单的查询文档的字符串表示形式：{ <field1>: < 1>, … }