mongodb配置文件解析

本文涉及的产品
云数据库 MongoDB,通用型 2核4GB
简介: 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 查询日志 比如find
replication 副本日志 比如同步心跳
sharding 分片日志 比如启动mongos
storage 存储日志 比如执行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。通常客户端将会使用连接池机制,可以有效的控制每个客户端的链接个数。
   wireObjectCheck: true #当客户端写入数据时,mongos/mongod是否检测数据的有效性(BSON),如果数据格式不良,此insert、update操作将会被拒绝;默认值为true。对于高程度的子文档嵌套的对象,net.wireobjectcheck对性能有较小的影响。
   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>: <expression1>, … }
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。 &nbsp; 相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
4月前
|
XML 数据采集 JavaScript
Java【XML 配置文件解析】
Java【XML 配置文件解析】
|
3月前
|
NoSQL MongoDB Python
深入了解 Python MongoDB 操作:排序、删除、更新、结果限制全面解析
使用 sort() 方法对结果进行升序或降序排序。 sort() 方法接受一个参数用于“字段名”,一个参数用于“方向”(升序是默认方向)。
68 0
|
4月前
|
存储 NoSQL Linux
MongoDB【部署 02】mongodb使用配置文件启动、添加为系统服务及自启动(一个报错:[13436][NotMasterOrSecondary])
MongoDB【部署 02】mongodb使用配置文件启动、添加为系统服务及自启动(一个报错:[13436][NotMasterOrSecondary])
222 0
|
6月前
|
存储 NoSQL Redis
Redis配置文件解析
Redis配置文件解析
64 1
|
7月前
|
NoSQL MongoDB 数据库
MongoDB 解析:灵活文档数据库与 Docker Compose 部署
`MongoDB` 是一款开源、高性能的 `NoSQL` 数据库,以其无模式的文档存储格式(BSON)而著称,广泛应用于众多开源项目,包括但不限于 Yapi 等。它在大规模数据存储和实时数据处理方面表现出色,因此备受青睐。在本文中,我们将深入探讨 `MongoDB` 的特性,并详细阐述如何使用 Docker Compose 轻松部署 `MongoDB` 数据库,为你提供全方位的指导。
240 1
MongoDB 解析:灵活文档数据库与 Docker Compose 部署
|
7月前
|
Java 应用服务中间件 Maven
解析Spring Boot中的Profile:配置文件与代码的双重掌控
解析Spring Boot中的Profile:配置文件与代码的双重掌控
|
3月前
|
NoSQL 关系型数据库 MySQL
深入了解 Python MongoDB 查询:find 和 find_one 方法完全解析
在 MongoDB 中,我们使用 find() 和 find_one() 方法来在集合中查找数据,就像在MySQL数据库中使用 SELECT 语句来在表中查找数据一样
65 1
|
3天前
|
Java 对象存储
Javaweb之SpringBootWeb案例之配置文件的详细解析
Javaweb之SpringBootWeb案例之配置文件的详细解析
9 0
|
3天前
|
XML Java 数据库连接
Javaweb之Mybatis的XML配置文件的详细解析
Javaweb之Mybatis的XML配置文件的详细解析
13 0
|
2月前
|
存储 JSON JavaScript
【YAML语法规范指南】从入门到精通,揭秘神秘语法,引领配置文件解析指南(基础结构篇)
"YAML Ain't Markup Language"(简称YAML)是一种专为人类设计的数据序列化语言,适用于多种现代编程语言,可广泛应用于各类日常任务。它是一种以人类可读形式呈现的、适用于多种语言的Unicode数据序列化标准。它基于敏捷编程中常见的本地数据结构,广泛应用于配置文件、互联网消息传递、对象持久化以及数据审计等多个领域。遵循Unicode标准、
119 8
【YAML语法规范指南】从入门到精通,揭秘神秘语法,引领配置文件解析指南(基础结构篇)

推荐镜像

更多