mongod.conf

1
$ vi /etc/mongod.conf

手册

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

进程管理

1
2
3
processManagement:
  fork: true  # fork and run in background
  pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile

网络

1
2
3
net:
  port: 27017
  bindIp: 127.0.0.1  # Listen to local interface only, comment to listen on all interfaces.

存储

1
2
3
4
5
6
7
storage:
  dbPath: /var/lib/mongo
  journal:
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

性能分析器

1
operationProfiling:

主从复制

1
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架构

1
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集群中，此值需要保持一致，集群启动后修改此值将不再生效。

系统日志

1
2
3
4
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

与安全有关的配置

1
2
3
4
5
6
7
8
security:  
    authorization: enabled  
    clusterAuthMode: keyFile  
    keyFile: /srv/mongodb/keyfile  
    javascriptEnabled: true  
setParameter:   
    enableLocalhostAuthBypass: true  
    authenticationMechanisms: SCRAM-SHA-1  

性能有关的参数

1
2
3
4
setParameter:  
    connPoolMaxShardedConnsPerHost: 200  
    connPoolMaxConnsPerHost: 200  
    notablescan: 0 

配置样例

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
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上增加如下配置：

1
2
3
4
replication:
    oplogSizeMB: 10240
    replSetName: rs0
    secondaryIndexPrefetch: all

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

1
2
3
sharding:
    clusterRole: shardsvr
    archiveMovedChunks: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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”，它将整理、压缩底层数据存储文件，重用磁盘空间，相当于数据重新整理了一遍，对数据优化有一定的作用。

1
$ ./mongod --dbpath=/data/mongodb/db --repair

mongodump与mongorestore

我们通常会使用到mongodb数据的备份功能，或者将一个备份导入到一个新的mongod实例中（数据冷处理），那么就需要借助这两个指令。

• 备份

1
>./mongodump --host m1.com --port 27017 -u root -p pass --out /data/mongodb/backup/dump_2015_10_10

• 还原

1
./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上进行的操作。

我的博客