1. 程式人生 > >MongoDB3.4版本配置詳解

MongoDB3.4版本配置詳解

配置說明

    在Mongod安裝包中,包含2個程序啟動檔案:mongod和mongos;其中mongd是核心基礎程序,用來接收讀寫請求、負責儲存實際資料,mongod例項是構成叢集的基本單位,比如Replication set、Sharding Cluster、Config Servers等;mongos是Sharding Cluster架構模式中的“路由”程序,即客戶端請求訪問mongos,然後有mongos將請求轉發給合適的sharding server執行操作,並將result返回給客戶端,所以mongos基本不儲存資料,只是在記憶體中快取部分shard key與sharding server的對應關係,便於路由。

    在配置檔案方面,mongod和mongos有很多相同之處,下文中如有區別之處將會特別指出。

    在一個節點上,通常同時啟動mongod和mongos程序是正常的,他們之間不存在資源競爭,但是為了避免衝突,我們希望它們使用各自的配置檔案,比如mongod.conf、mongos.conf;mongodb的某些平臺下的安裝包中沒有自帶配置檔案,需要開發者自己建立。

重要配置引數講解如下:

  • processManagement:

fork: <true | false>

 描述:是否以fork模式執行mongod/mongos程序,預設為false。

pidFilePath:<路徑>

描述:配合"fork:true"引數,將mongod/mongos程序ID寫入指定的檔案,如果不指定,將不會建立PID檔案。

  • net:

bindIp: <127.0.0.1>

描述:mongod/monogs程序繫結的IP,application通過此IP、port建立連結。可以繫結在任意網絡卡介面上,如果你的mongos/mongod只需要內網訪問,可以繫結在內網IP(例如:192.168.1.100),如果需要外網訪問,那麼則繫結外網IP,如果此值為“0.0.0.0”,則繫結到所有介面即內網、外網IP均可以訪問。(不建議)可以繫結都多個ip上,ip地址之間用“,”分割。

port: 27017

描述:mongod/mongos偵聽埠,預設為27017;不過因為mongodb有2種典型的架構模式:replica set和sharding,如果開發者在一個節點上部署多個mongod例項,需要注意修改此埠以避免衝突。

maxIncomingConnections: 65536

描述:mongod/mongos程序允許的最大連線數,如果此值超過作業系統配置的連線數閥值,將不會生效(ulimit);預設值為65536。通常客戶端將會使用連線池機制,可以有效的控制每個客戶端的連結個數。

wireObjectCheck: true

描述:當客戶端寫入資料時,mongos/mongod是否檢測資料的有效性(BSON),如果資料格式不良,此insert、update操作將會被拒絕;預設值為true

ipv6: false

描述:是否支援mongos/mongod多個例項之間使用IPV6網路,預設值為false。此值需要在整個cluster中保持一致。

  • storage:

dbPath: db

描述:mongod程序儲存資料目錄,此配置僅對mongod程序有效。預設值為:/data/db。

indexBuildRetry: true

描述:當構建索引時mongod意外關閉,那麼再次啟動是否重新構建索引;索引構建失敗,mongod重啟後將會刪除尚未完成的索引,但是否重建由此引數決定。預設值為true。

repairPath: _tmp

描述:配合--repair啟動命令引數,在repair期間使用此目錄儲存臨時資料,repair結束後此目錄下資料將被刪除,此配置僅對mongod程序有效。不建議在配置檔案中配置,而是使用mongod啟動命令指定。

engine: mmapv1

描述:儲存引擎型別,mongodb 3.0之後支援“mmapv1”、“wiredTiger”兩種引擎,預設值為“mmapv1”;官方宣稱wiredTiger引擎更加優秀。

journal:

enabled: true

描述:是否開啟journal日誌持久儲存,journal日誌用來資料恢復,是mongod最基礎的特性,通常用於故障恢復。64位系統預設為true,32位預設為false,建議開啟,僅對mongod程序有效。

directoryPerDB: false

描述:是否將不同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有效。

mmapv1:(如下配置僅對MMAPV1引擎生效)

quota:

enforced: false

描述:配額管理,是否限制每個DB所能持有的最大檔案數量,僅對mongod有效,預設值為false,建議保持預設值。

maxFilesPerDB: 8

描述:如果enforce開啟,每個DB所持有的儲存檔案不會超過此閥值。僅對mongod程序有效。

smallFiles: false

描述:是否使用小檔案儲存資料;如果此值為true,mongod將會限定每個資料檔案的大小為512M(預設最大為2G),journal降低到128M(預設為1G)。如果DB的資料量較大,將會導致每個DB建立大量的小檔案,這對效能有一定的影響。在production環境下,不建議修改此值,在測試時可以設定為true,節約磁碟。

journal:

commitIntervalMs: 100

描述:mongod程序提交journal日誌的時間間隔,即fsync的間隔。考慮到磁碟效能,mongod間歇性的flush日誌資料;此值越小,資料丟失的可能性越低,磁碟消耗越大,效能越低。如果希望write操作強制立即寫入journal,可以傳遞引數選項“j:true”(在客戶端write操作中指定此選項即可),此操作(包括此前尚未提交的)將會立即fsync到磁碟。僅對mongod有效,單位:毫秒

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來同步資料,只能全量同步。此值僅對mongod有效。

enableMajorityReadConcern: false

描述:是否開啟readConcern的級別為“majority”,預設為false;只有開啟此選項,才能在read操作中使用“majority”。(3.2+版本)

replSetName: <無預設值>

描述:“複製集”的名稱,複製集中的所有mongd例項都必須有相同的名字,sharding分散式下,不同的sharding應該使用不同的replSetName。僅對mongod有效。

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節點。僅對mongos有效。

  • 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例項必須配置一樣,否則可能帶來不必要的問題。僅對mongos有效

chunkSize: 64

描述:sharded叢集中每個chunk的大小,單位:MB,預設為64,此值對於絕大多數應用而言都是比較理想的。chunkSize太大會導致分佈不均,太小會導致分裂成大量的chunk而經常移動

##整個sharding叢集中,此值需要保持一致,叢集啟動後修改此值將不再生效。僅對mongos有效

  • sytemsLog:(系統日誌,必須配置)

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。

localPingThresholdMsdestination: file

描述:日誌輸出目的地,可以指定為“ file”或者“syslog”,表述輸出到日誌檔案,如果不指定,則會輸出到標準輸出中(standard output)。

  • 與安全有關的配置(摘要介紹)
    1. security:  
    2.     authorization: enabled  
    3.     clusterAuthMode: keyFile  
    4.     keyFile: /srv/mongodb/keyfile  
    5.     javascriptEnabled: true  
    6. setParameter:   
    7.     enableLocalhostAuthBypass: true  
    8.     authenticationMechanisms: SCRAM-SHA-1  

1)authorization:disabled或者enabled,僅對mongod有效;表示是否開啟使用者訪問控制(Access Control),即客戶端可以通過使用者名稱和密碼認證的方式訪問系統的資料,預設為“disabled”,即客戶端不需要密碼即可訪問資料庫資料。(限定客戶端與mongod、mongos的認證)

2)clusterAuthMode:叢集中members之間的認證模式,可選值為“keyFile”、“sendKeyFile”、“sendX509”、“x509”,對mongod/mongos有效;預設值為“keyFile”,mongodb官方推薦使用x509,不過我個人覺得還是keyFile比較易於學習和使用。不過3.0版本中,mongodb增加了對TLS/SSL的支援,如果可以的話,建議使用SSL相關的配置來認證叢集的member,此文將不再介紹。(限定叢集中members之間的認證)

3)keyFile:當clusterAuthMode為“keyFile”時,此引數指定keyfile的位置,mongodb需要有訪問此檔案的許可權。

4)javascriptEnabled:true或者false,預設為true,僅對mongod有效;表示是否關閉server端的javascript功能,就是是否允許mongod上執行javascript指令碼,如果為false,那麼mapreduce、group命令等將無法使用,因為它們需要在mongod上執行javascript指令碼方法。如果你的應用中沒有mapreduce等操作的需求,為了安全起見,可以關閉javascript。

“setParameter”允許指定一些的Server端引數,這些引數不依賴於儲存引擎和互動機制,只是微調系統的執行狀態,比如“認證機制”、“執行緒池引數”等。參見【parameter

    1)enableLocalhostAuthBypass:true或者false,預設為true,對mongod/mongos有效;表示是否開啟“localhost exception”,對於sharding cluster而言,我們傾向於在mongos上開啟,在shard節點的mongod上關閉。

    2)authenticationMechanisms:認證機制,可選值為“SCRAM-SHA-1”、“MONGODB-CR”、“PLAN”等,建議為“SCRAM-SHA-1”,對mongod/mongos有效;一旦選定了認證機制,客戶端訪問databases時需要與其匹配才能有效。

  • 與效能有關的引數
    1. setParameter:  
    2.     connPoolMaxShardedConnsPerHost: 200  
    3.     connPoolMaxConnsPerHost: 200  
    4.     notablescan: 0  

1)connPoolMaxShardedConnsPerHost:預設值為200,對mongod/mongos有效;表示當前mongos或者shard與叢集中其他shards連結的連結池的最大容量,此值我們通常不會調整。連線池的容量不會阻止建立新的連結,但是從連線池中獲取連結的個數不會超過此值。維護連線池需要一定的開支,保持一個連結也需要佔用一定的系統資源。

 2)connPoolMaxConnsPerHost:預設值為200,對mongod/mongos有效;同上,表示mongos或者mongod與其他mongod例項之間的連線池的容量,根據host限定。

配置樣例

普通mongod節點

  1. systemLog:  
  2.     quiet: false  
  3.     path: /data/mongodb/logs/mongod.log  
  4.     logAppend: false  
  5.     destination: file  
  6. processManagement:  
  7.     fork: true  
  8.     pidFilePath: /data/mongodb/mongod.pid  
  9. net:  
  10.     bindIp: 127.0.0.1  
  11.     port: 27017  
  12.     maxIncomingConnections: 65536  
  13.     wireObjectCheck: true  
  14.     ipv6: false   
  15. storage:  
  16.     dbPath: /data/mongodb/db  
  17.     indexBuildRetry: true  
  18.     journal:  
  19.         enabled: true  
  20.     directoryPerDB: false  
  21.     engine: mmapv1  
  22.     syncPeriodSecs: 60   
  23.     mmapv1:  
  24.         quota:  
  25.             enforced: false  
  26.             maxFilesPerDB: 8  
  27.         smallFiles: true      
  28.         journal:  
  29.             commitIntervalMs: 100  
  30.     wiredTiger:  
  31.         engineConfig:  
  32.             cacheSizeGB: 8  
  33.             journalCompressor: snappy  
  34.             directoryForIndexes: false    
  35.         collectionConfig:  
  36.             blockCompressor: snappy  
  37.         indexConfig:  
  38.             prefixCompression: true  
  39. operationProfiling:  
  40.     slowOpThresholdMs: 100  
  41.     mode: off  

如果你的架構模式為replication Set,那麼還需要在所有的“複製集”members上增加如下配置: 

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

如果為sharding Cluster架構,則需要在shard節點增加如下配置:  

  1. sharding:  
  2.     clusterRole: shardsvr  
  3.     archiveMovedChunks: true  

當然,一個mongod例項即可以為“複製集”的member之一,也可以作為sharding叢集中的一個分片,這取決你的架構模式。

mongod程序可以做為“config server”例項,只需要將“clusterRole: configsvr”即可;由此可見,一個mongod例項可以為“單點例項”、“config server”、“sharding server” + “replication set member”其中一個角色,建議使用不同的配置檔案啟動它。

路由節點

  1. systemLog:  
  2.     quiet: false  
  3.     path: /data/mongodb/logs/mongod.log  
  4.     logAppend: false  
  5.     destination: file  
  6. processManagement:  
  7.     fork: true  
  8.     pidFilePath: /data/mongodb/mongod.pid  
  9. net:  
  10.     bindIp: 127.0.0.1  
  11.     port: 37017  
  12.     maxIncomingConnections: 65536  
  13.     wireObjectCheck: true  
  14.     ipv6: false   
  15. replication:  
  16.     localPingThresholdMs: 15              
  17. sharding:  
  18.     autoSplit: true  
  19.     configDB: m1.com:27018,m2.com:27018,m3.com:27018  
  20.     chunkSize: 64  
mongos例項不需要儲存實際的資料,對記憶體有一定的消耗,在sharding架構模式下使用;mongos需接收向客戶端請求(後端的sharded和replication set則不需要讓客戶端知道),它可以將客戶端請求轉發到一個分片叢集上(分片叢集基於複製集)延遲相對較小的secondary上,同時還負責chunk的分裂和遷移工作。

其他

repair

   “修復”資料庫,當mongodb執行一段時間之後,特別是經過大量刪除、update操作之後,我們可以使用repair指令對資料儲存進行“repair”,它將整理、壓縮底層資料儲存檔案,重用磁碟空間,相當於資料重新整理了一遍,對資料優化有一定的作用。

    如果mongod沒有開啟journaling日誌功能,repair指令可以在系統異常crash之後,用於整理資料、消除損壞資料;如果開啟了journaling日誌功能,我們則需不要使用repair來修復資料,因為journal就可以幫助mongod恢復資料。在replication set模式下,可以使用repair,但是通常可以直接刪除舊資料,使用“資料同步”操作,即可達到“恢復”、“整理”資料的目的,效果和repair一樣,而且效率更高。

    repair需要磁碟有一定的剩餘空間,為當前database資料量 + 2GB,可以通過使用“--repairpath”來指定repair期間儲存臨時資料的目錄。repair指令還會重建indexes,可以降低索引的資料大小。

    如果mongod意外crash,需要首先正常啟動mongod,讓根據journal日誌恢復完資料之後,才能執行repair;如果journal日誌有資料尚未恢復,那麼使用repair指令啟動mongod將會失敗。

    repair時需要關閉mongod程序,執行完畢後再啟動。

  1. mongod --dbpath=/data/mongodb/db --repair  
mongodb比較傾向於使用shell來repair特定的database,這個操作相對比較可控,其內部工作機制一樣。
  1. >./mongo  
  2. >user mydatabase;  
  3. >db.repairDatabase();  

mongodump與mongorestore

我們通常會使用到mongodb資料的備份功能,或者將一個備份匯入到一個新的mongod例項中(資料冷處理),那麼就需要藉助這兩個指令。

mongodump將整個databases全部內容匯出到一個二進位制檔案中,可以在其他mongod使用mongorestore來載入整個檔案。需要注意mongodump不會匯出“local”資料庫中的資料,當然這個local庫對恢復資料也沒有太大意義。

    “-u”引數指定訪問database的使用者名稱,“-p”指定密碼,“--host”和“--port”指定mongod例項的位置,“--db”指定需要dump的資料庫,如果不指定則dump所有資料庫,“--collection”指定需要dump的集合表,如