mongoose 配置文件详解 | 宋宇的文档笔记

config 配置文件详解

mongod.conf

linux：vi /etc/mongod.conf

手册

https://docs.mongodb.com/manual/reference/configuration-options
https://docs.mongodb.com/manual/reference/parameters/

进程管理

processManagement:

  fork: true  # fork and run in background

  pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile

1
2
3
4
5
6

fork: 运行在后台
pidFilePath：PID 文件路径

网络

net:

  port: 27017

  bindIp: 127.0.0.1  # Listen to local interface only, comment to listen on all interfaces.

1
2
3
4
5

port：端口
bindIp：绑定外网 op 多个用逗号分隔
maxIncomingConnections：进程允许的最大连接数默认值为 65536
wireObjectCheck：当客户端写入数据时检测数据的有效性 (BSON) 默认值为 true
ipv6：默认值为 false

存储

storage:

  dbPath: /var/lib/mongo

  journal:

    enabled: true

#  engine:

#  mmapv1:

#  wiredTiger:

1
2
3
4
5
6
7
8
9
10
11
12
13

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: 配额管理，是否限制每个 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

1
2
3
4
5
6
7

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

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

1
2
3
4
5
6
7

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

如果你的架构模式为 replication Set，那么还需要在所有的 “复制集”members 上增加如下配置：

replication:

    oplogSizeMB: 10240

    replSetName: rs0

    secondaryIndexPrefetch: all

1
2
3
4
5
6
7

如果为 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

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/82585778open in new window

# config 配置文件详解

# mongod.conf

# 手册

# 进程管理

# 网络

# 存储

# 性能分析器

# 主从复制

# sharding 架构

# 系统日志

# 与安全有关的配置

# 性能有关的参数

# 配置样例

# 如果你的架构模式为 replication Set，那么还需要在所有的 “复制集”members 上增加如下配置：

# 如果为 sharding Cluster 架构，则需要在 shard 节点增加如下配置：

# repair 修复

# mongodump 与 mongorestore

# 备份

# 还原

# mongoimport 和 mongoexport

# mongo shell

config 配置文件详解

mongod.conf

手册

进程管理

网络

存储

性能分析器

主从复制

sharding 架构

系统日志

与安全有关的配置

性能有关的参数

配置样例

如果你的架构模式为 replication Set，那么还需要在所有的 “复制集”members 上增加如下配置：

如果为 sharding Cluster 架构，则需要在 shard 节点增加如下配置：

repair 修复

mongodump 与 mongorestore

备份

还原

mongoimport 和 mongoexport

mongo shell