mongod.conf
$ vi /etc/mongod.conf
手册
https://docs.mongodb.com/manual/reference/configuration-options
进程管理
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
名称 |
说明 |
fork |
运行在后台 |
pidFilePath |
PID 文件路径 |
网络
net:
port: 27017
bindIp: 127.0.0.1 # Listen to local interface only, comment to listen on all interfaces.
名称 |
说明 |
port |
端口 |
bindIp |
绑定外网 op 多个用逗号分隔 |
maxIncomingConnections |
进程允许的最大连接数 默认值为 65536 |
wireObjectCheck |
当客户端写入数据时 检测数据的有效性 (BSON) 默认值为 true |
ipv6 |
默认值为 false |
存储
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# engine:
# mmapv1:
# wiredTiger:
名称 |
说明 |
dbPath |
mongod 进程存储数据目录,此配置仅对 mongod 进程有效 |
indexBuildRetry |
当构建索引时 mongod 意外关闭,那么再次启动是否重新构建索引;索引构建失败,mongod 重启后将会删除尚未完成的索引,但是否重建由此参数决定。默认值为 true。 |
repairPath |
配合 --repair 启动命令参数,在 repair 期间使用此目录存储临时数据,repair 结束后此目录下数据将被删除,此配置仅对 mongod 进程有效。不建议在配置文件中配置,而是使用 mongod 启动命令指定。 |
engine |
存储引擎类型,mongodb 3.0 之后支持 “mmapv1”、“wiredTiger” 两种引擎,默认值为“mmapv1”;官方宣称 wiredTiger 引擎更加优秀。 |
journal |
是否开启 journal 日志持久存储,journal 日志用来数据恢复,是 mongod 最基础的特性,通常用于故障恢复。64 位系统默认为 true,32 位默认为 false,建议开启,仅对 mongod 进程有效。 |
directoryPerDB |
是否将不同 DB 的数据存储在不同的目录中 默认值为 false |
syncPeriodSecs |
mongod 使用 fsync 操作将数据 flush 到磁盘的时间间隔,默认值为 60(单位:秒)强烈建议不要修改此值 mongod 将变更的数据写入 journal 后再写入内存,并间歇性的将内存数据 flush 到磁盘中,即延迟写入磁盘,有效提升磁盘效率 |
mmapv1 |
仅对 MMAPV1 引擎 |
quota: |
|
enforced:false |
配额管理,是否限制每个 DB 所能持有的最大文件数量 默认值为 false |
maxFilesPerDB:8 |
如果 enforce 开启,每个 DB 所持有的存储文件不会超过此阀值 |
smallFiles: false |
是否使用小文件存储数据;如果此值为 true mongod 将会限定每个数据文件的大小为 512M(默认最大为 2G),journal 降低到 128M(默认为 1G)。如果 DB 的数据量较大,将会导致每个 DB 创建大量的小文件,这对性能有一定的影响。在 production 环境下,不建议修改此值,在测试时可以设置为 true,节约磁盘。 |
journal: |
|
commitIntervalMs: 100 |
mongod 进程提交 journal 日志的时间间隔,即 fsync 的间隔。单位:毫秒 |
nsSize: |
每个 database 的 namespace 文件的大小,默认为 16,单位:M;最大值可以设置为 2048,即 dbpath 下 “.ns” 后缀文件的大小。16M 基本上可以保存 24000 条命名条目,新建一个 collection 或者 index 信息,即会增加一个 namespace 条目;如果你的 database 下需要创建大量的 collection(比如数据分析),则可以适度调大此值。 |
wiredTiger |
如下配置仅对 wiredTiger 引擎生效(3.0 以上版本) |
engineConfig: |
|
cacheSizeGB: 8 |
wiredTiger 缓存工作集(working set)数据的内存大小,单位:GB,此值决定了 wiredTiger 与 mmapv1 的内存模型不同,它可以限制 mongod 对内存的使用量,而 mmapv1 则不能(依赖于系统级的 mmap)。默认情况下,cacheSizeGB 的值为假定当前节点只部署一个 mongod 实例,此值的大小为物理内存的一半;如果当前节点部署了多个 mongod 进程,那么需要合理配置此值。如果 mongod 部署在虚拟容器中(比如,lxc,cgroups,Docker)等,它将不能使用整个系统的物理内存,则需要适当调整此值。默认值为物理内存的一半。 |
journalCompressor: snappy |
journal 日志的压缩算法,可选值为 “none”、“snappy”、“zlib”。 |
directoryForIndexes: false |
是否将索引和 collections 数据分别存储在 dbPath 单独的目录中。即 index 数据保存 “index” 子目录,collections 数据保存在 “collection” 子目录。默认值为 false,仅对 mongod 有效。 |
collectionConfig: |
|
blockCompressor: snappy |
collection 数据压缩算法,可选值 “none”、“snappy”、“zlib”。开发者在创建 collection 时可以指定值,以覆盖此配置项。如果 mongod 中已经存在数据,修改此值不会带来问题,旧数据仍然使用原来的算法解压,新数据文件将会采用新的解压缩算法。 |
indexConfig: |
|
prefixCompression: true |
是否对索引数据使用 “前缀压缩”(prefix compression,一种算法)。前缀压缩,对那些经过排序的值存储,有很大帮助,可以有效的减少索引数据的内存使用量。默认值为 true。 |
性能分析器
operationProfiling:
名称 |
说明 |
slowOpThresholdMs: 100 |
数据库 profiler 判定一个操作是 “慢查询” 的时间阀值,单位毫秒;mongod 将会把慢查询记录到日志中,即使 profiler 被关闭。当 profiler 开启时,慢查询记录还会被写入 “system.profile” 这个系统级的 collection 中。请参看 mongod profiler 相关文档。默认值为 100,此值只对 mongod 进程有效。 |
mode: off |
数据库 profiler 级别,操作的性能信息将会被写入日志文件中,可选值: |
1)off:关闭 profiling |
|
2)slowOp:on,只包含慢操作日志 |
|
3)all:on,记录所有操作 |
|
数据库 profiling 会影响性能,建议只在性能调试阶段开启。此参数仅对 mongod 有效。 |
主从复制
replication:
名称 |
说明 |
oplogSizeMB: 10240 |
replication 操作日志的最大尺寸,单位:MB。mongod 进程根据磁盘最大可用空间来创建 oplog,比如 64 位系统,oplog 为磁盘可用空间的 5%,一旦 mongod 创建了 oplog 文件,此后再次修改 oplogSizeMB 将不会生效。此值不要设置的太小, 应该足以保存 24 小时的操作日志,以保证 secondary 有充足的维护时间;如果太小,secondary 将不能通过 oplog 来同步数据,只能全量同步。 |
enableMajorityReadConcern: false |
是否开启 readConcern 的级别为 “majority”,默认为 false;只有开启此选项,才能在 read 操作中使用 “majority”。(3.2 + 版本) |
replSetName: <无默认值> |
“复制集” 的名称,复制集中的所有 mongd 实例都必须有相同的名字,sharding 分布式下,不同的 sharding 应该使用不同的 replSetName |
secondaryIndexPrefetch: all |
只对 mmapv1 存储引擎有效。复制集中的 secondary,从 oplog 中运用变更操作之前,将会先把索引加载到内存中,默认情况下,secondaries 首先将操作相关的索引加载到内存,然后再根据 oplog 应用操作。可选值: |
1)none:secondaries 不将索引数据加载到内容 |
|
2)all:sencondaries 将此操作有关的索引数据加载到内存 |
|
3)_id_only:只加载_id 索引 |
|
默认值为:all,此配置仅对 mongod 有效。 |
|
localPingThresholdMs: 15 |
ping 时间,单位:毫秒,mongos 用来判定将客户端 read 请求发给哪个 secondary。仅对 mongos 有效。默认值为 15,和客户端 driver 中的默认值一样。当 mongos 接收到客户端 read 请求,它将: |
1、找出复制集中 ping 值最小的 member。 |
|
2、将延迟值被此值允许的 members,构建一个列表 |
|
3、从列表中随机选择一个 member。 |
|
ping 值是动态值,每 10 秒计算一次。mongos 将客户端请求转发给延迟较小(与此值相比)的某个 secondary 节点。 |
sharding 架构
sharding:
名称 |
说明 |
clusterRole: <无默认值> |
在 sharding 集群中,此 mongod 实例的角色,可选值: |
1、configsvr:此实例为 config server,此实例默认侦听 27019 端口 |
|
2、shardsvr:此实例为 shard(分片),侦听 27018 端口 |
|
此配置仅对 mongod 有效。通常 config server 和 sharding server 需要使用各自的配置文件。 |
|
archiveMovedChunks: true |
当 chunks 因为 “负载平衡” 而迁移到其他节点时,mongod 是否将这些 chunks 归档,并保存在 dbPath 下 “moveChunk” 目录下,mongod 不会删除 moveChunk 下的文件。默认为 true。 |
autoSplit: true |
是否开启 sharded collections 的自动分裂,仅对 mongos 有效。如果所有的 mongos 都设定为 false,那么 collections 数据增长但不能分裂成新的 chunks。因为集群中任何一个 mongos 进程都可以触发 split,所以此值需要在所有 mongos 行保持一致。仅对 mongos 有效。 |
configDB: <无默认值> |
设定 config server 的地址列表,每个 server 地址之间以 “,” 分割,通常 sharded 集群中指定 1 或者 3 个 config server。(生产环境,通常是 3 个 config server,但 1 个也是可以的)。所有的 mongos 实例必须配置一样,否则可能带来不必要的问题。 |
chunkSize: 64 |
sharded 集群中每个 chunk 的大小,单位:MB,默认为 64,此值对于绝大多数应用而言都是比较理想的。chunkSize 太大会导致分布不均,太小会导致分裂成大量的 chunk 而经常移动. 整个 sharding 集群中,此值需要保持一致,集群启动后修改此值将不再生效。 |
系统日志
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
名称 |
说明 |
verbosity: 0 |
日志级别,0:默认值,包含 “info” 信息,1~5,即大于 0 的值均会包含 debug 信息 |
quiet: true |
"安静",此时 mongod/mongos 将会尝试减少日志的输出量。不建议在 production 环境下开启,否则将会导致跟踪错误比较困难。 |
traceAllExceptions: true |
打印异常详细信息。 |
path: logs/mongod.log |
日志路径 |
logAppend: false |
如果为 true,当 mongod/mongos 重启后,将在现有日志的尾部继续添加日志。否则,将会备份当前日志文件,然后创建一个新的日志文件;默认为 false。 |
logRotate: rename |
日志 “回转”,防止一个日志文件特别大,则使用 logRotate 指令将文件 “回转”,可选值: |
1)rename:重命名日志文件,默认值。 |
|
2)reopen:使用 linux 日志 rotate 特性,关闭并重新打开此日志文件,可以避免日志丢失,但是 logAppend 必须为 true。 |
|
destination: file |
日志输出目的地,可以指定为 “file” 或者“syslog”,表述输出到日志文件,如果不指定,则会输出到标准输出中(standard output) |
与安全有关的配置
security:
authorization: enabled
clusterAuthMode: keyFile
keyFile: /srv/mongodb/keyfile
javascriptEnabled: true
setParameter:
enableLocalhostAuthBypass: true
authenticationMechanisms: SCRAM-SHA-1
名称 |
说明 |
authorization |
disabled 或者 enabled,仅对 mongod 有效;表示是否开启用户访问控制(Access Control),即客户端可以通过用户名和密码认证的方式访问系统的数据,默认为 “disabled”,即客户端不需要密码即可访问数据库数据。(限定客户端与 mongod、mongos 的认证) |
clusterAuthMode |
集群中 members 之间的认证模式,可选值为 “keyFile”、“sendKeyFile”、“sendX509”、“x509”,对 mongod/mongos 有效;默认值为 “keyFile”,mongodb 官方推荐使用 x509,不过我个人觉得还是 keyFile 比较易于学习和使用。不过 3.0 版本中,mongodb 增加了对 TLS/SSL 的支持,如果可以的话,建议使用 SSL 相关的配置来认证集群的 member,此文将不再介绍。(限定集群中 members 之间的认证) |
keyFile |
当 clusterAuthMode 为 “keyFile” 时,此参数指定 keyfile 的位置,mongodb 需要有访问此文件的权限。 |
javascriptEnabled |
true 或者 false,默认为 true,仅对 mongod 有效;表示是否关闭 server 端的 javascript 功能,就是是否允许 mongod 上执行 javascript 脚本,如果为 false,那么 mapreduce、group 命令等将无法使用,因为它们需要在 mongod 上执行 javascript 脚本方法。如果你的应用中没有 mapreduce 等操作的需求,为了安全起见,可以关闭 javascript。 |
setParameter |
允许指定一些的 Server 端参数,这些参数不依赖于存储引擎和交互机制,只是微调系统的运行状态,比如 “认证机制”、“线程池参数” 等。参见【parameter】 |
enableLocalhostAuthBypass |
true 或者 false,默认为 true,对 mongod/mongos 有效;表示是否开启 “localhost exception”,对于 sharding cluster 而言,我们倾向于在 mongos 上开启,在 shard 节点的 mongod 上关闭。 |
authenticationMechanisms |
认证机制,可选值为 “SCRAM-SHA-1”、“MONGODB-CR”、“PLAN” 等,建议为“SCRAM-SHA-1”,对 mongod/mongos 有效;一旦选定了认证机制,客户端访问 databases 时需要与其匹配才能有效。 |
性能有关的参数
setParameter:
connPoolMaxShardedConnsPerHost: 200
connPoolMaxConnsPerHost: 200
notablescan: 0
名称 |
说明 |
connPoolMaxShardedConnsPerHost |
默认值为 200,对 mongod/mongos 有效;表示当前 mongos 或者 shard 与集群中其他 shards 链接的链接池的最大容量,此值我们通常不会调整。连接池的容量不会阻止创建新的链接,但是从连接池中获取链接的个数不会超过此值。维护连接池需要一定的开支,保持一个链接也需要占用一定的系统资源。 |
connPoolMaxConnsPerHost |
默认值为 200,对 mongod/mongos 有效;同上,表示 mongos 或者 mongod 与其他 mongod 实例之间的连接池的容量,根据 host 限定。 |
配置样例
systemLog:
quiet: false
path: /data/mongodb/logs/mongod.log
logAppend: false
destination: file
processManagement:
fork: true
pidFilePath: /data/mongodb/mongod.pid
net:
bindIp: 127.0.0.1
port: 27017
maxIncomingConnections: 65536
wireObjectCheck: true
ipv6: false
storage:
dbPath: /data/mongodb/db
indexBuildRetry: true
journal:
enabled: true
directoryPerDB: false
engine: mmapv1
syncPeriodSecs: 60
mmapv1:
quota:
enforced: false
maxFilesPerDB: 8
smallFiles: true
journal:
commitIntervalMs: 100
wiredTiger:
engineConfig:
cacheSizeGB: 8
journalCompressor: snappy
directoryForIndexes: false
collectionConfig:
blockCompressor: snappy
indexConfig:
prefixCompression: true
operationProfiling:
slowOpThresholdMs: 100
mode: off
如果你的架构模式为 replication Set,那么还需要在所有的 “复制集”members 上增加如下配置:
replication:
oplogSizeMB: 10240
replSetName: rs0
secondaryIndexPrefetch: all
如果为 sharding Cluster 架构,则需要在 shard 节点增加如下配置:
sharding:
clusterRole: shardsvr
archiveMovedChunks: true
systemLog:
quiet: false
path: /data/mongodb/logs/mongod.log
logAppend: false
destination: file
processManagement:
fork: true
pidFilePath: /data/mongodb/mongod.pid
net:
bindIp: 127.0.0.1
port: 37017
maxIncomingConnections: 65536
wireObjectCheck: true
ipv6: false
replication:
localPingThresholdMs: 15
sharding:
autoSplit: true
configDB: m1.com:27018,m2.com:27018,m3.com:27018
chunkSize: 64
mongos 实例不需要存储实际的数据,对内存有一定的消耗,在 sharding 架构模式下使用;mongos 需接收向客户端请求(后端的 sharded 和 replication set 则不需要让客户端知道),它可以将客户端请求转发到一个分片集群上(分片集群基于复制集)延迟相对较小的 secondary 上,同时还负责 chunk 的分裂和迁移工作。
repair 修复
“修复” 数据库,当 mongodb 运行一段时间之后,特别是经过大量删除、update 操作之后,我们可以使用 repair 指令对数据存储进行 “repair”,它将整理、压缩底层数据存储文件,重用磁盘空间,相当于数据重新整理了一遍,对数据优化有一定的作用。
$ ./mongod --dbpath=/data/mongodb/db --repair
mongodump 与 mongorestore
我们通常会使用到 mongodb 数据的备份功能,或者将一个备份导入到一个新的 mongod 实例中(数据冷处理),那么就需要借助这两个指令。
-
备份
>./mongodump --host m1.com --port 27017 -u root -p pass --out /data/mongodb/backup/dump_2015_10_10
-
还原
./mongorestore --db mydatabase /data/mongodb/backup/dump_2015_10_10
mongoimport 和 mongoexport
mongoexport 将数据导出为 JSON 或者 CSV 格式,以便其他应用程序解析。
mongo shell
1)help:列出所有的 function
2)show dbs:展示当前实例中所有的 databases。
3)use :切换到指定的 db,接下来的操作将会在此 db 中。
4)show collections:展示出当前 db 中所有的 collections。
5)show users:展示当前 db 中已经添加的所有用户。
6)show roles:展示当前 db 中所有内置的或者自定义的用户角色。
7)show profile:这涉及到 profile 相关的配置,默认情况下展示出最近 5 个操作耗时超过 1 秒的操作,通常用于跟踪慢查询。
8)db.help():展示出可以在 db 上进行的操作 function。
9)db..help():展示出可以在 colleciton 上进行的操作。
原文来自:https://blog.csdn.net/MatrixGod/article/details/82585778