MongoDB 常用運維實踐總結(jié)

一、MongoDB 集群簡介

MongoDB是一個基于分布式文件存儲的數(shù)據(jù)庫，其目的在于為WEB應(yīng)用提供可擴展的高性能數(shù)據(jù)存儲解決方案。下面將以3臺機器介紹最常見的集群方案。具體介紹，可以查看官網(wǎng) https://docs.mongodb.com/v3.4/introduction/。

1、集群組件的介紹

• mongos（路由處理）：作為Client與MongoDB集群的請求入口，所有用戶請求都會透過Mongos協(xié)調(diào)，它會將數(shù)據(jù)請求發(fā)到對應(yīng)的Shard(mongod)服務(wù)器上，再將數(shù)據(jù)合并后回傳給用戶。
• config server（配置節(jié)點）：即：配置服務(wù)器；主要保存數(shù)據(jù)庫的元數(shù)據(jù)，包含數(shù)據(jù)的分布(分片)以及數(shù)據(jù)結(jié)構(gòu)，mongos收到client發(fā)出的需求后，會從config server加載配置信息并緩存于內(nèi)存中。 一般在生產(chǎn)環(huán)境會配置不只一臺config server，因為它保存的元數(shù)據(jù)極為重要，若損壞則影響整個集群運作。
• shard（分片實例存儲數(shù)據(jù)）：shard就是分片。MongoDB利用分片的機制來實現(xiàn)數(shù)據(jù)分布存儲與處理，達到橫向擴容的目的。默認情況下，數(shù)據(jù)在分片之間會自動進行移轉(zhuǎn)，以達到平衡，此動作是靠一個叫平衡器(balancer)的機制達成。
• replica set（副本集）：副本集實現(xiàn)了數(shù)據(jù)庫高可用，若沒做副本集，則一旦存放數(shù)據(jù)的服務(wù)器節(jié)點掛掉，數(shù)據(jù)就丟失了，相反若配置了副本集，則同樣的數(shù)據(jù)會保存在副本服務(wù)器中(副本節(jié)點)，一般副本集包含了一個主節(jié)點與多個副本節(jié)點，必要時還會配置arbiter(仲裁結(jié)點)作為節(jié)點掛掉時投票用。
• arbiter（仲裁節(jié)點）：仲裁服務(wù)器本身不包含數(shù)據(jù)，僅能在主節(jié)點故障時，檢測所有副本服務(wù)器并選舉出新的主節(jié)點，其實現(xiàn)方式是通過主節(jié)點、副本節(jié)點、仲裁服務(wù)器之間的心跳(Heart beat)實現(xiàn)。

2、MongoDB應(yīng)用場景

• 網(wǎng)站數(shù)據(jù)：適合實時的插入，更新與查詢，并具備網(wǎng)站實時數(shù)據(jù)存儲所需的復(fù)制及高度伸縮性。
• 緩存：由于性能很高，也適合作為信息基礎(chǔ)設(shè)施的緩存層。在系統(tǒng)重啟之后，搭建的持久化緩存可以避免下層的數(shù)據(jù)源過載。
• 大尺寸、低價值的數(shù)據(jù)：使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫存儲一些數(shù)據(jù)時可能會比較貴，在此之前，很多程序員往往會選擇傳統(tǒng)的文件進行存儲。
• 高伸縮性的場景：非常適合由數(shù)十或者數(shù)百臺服務(wù)器組成的數(shù)據(jù)庫。
• 用于對象及JSON數(shù)據(jù)的存儲：MongoDB的BSON數(shù)據(jù)格式非常適合文檔格式化的存儲及查詢。

3、選用MongoDB的緣由

選用MongoDB的數(shù)據(jù)是以BSON的數(shù)據(jù)格式，高度伸縮方便擴展，并且數(shù)據(jù)水平擴展非常簡單，支持海量數(shù)據(jù)存儲，性能強悍。

二、集群的監(jiān)測

1、監(jiān)測數(shù)據(jù)庫存儲統(tǒng)計信息

docker中進入mongos或shard實例，執(zhí)行以下命令：

docker exec -it mongos bash;
mongo --port 20001;
use admin;
db.auth("root","XXX");

說明:通過此命令，可以查詢集群的成員的集合數(shù)量、索引數(shù)量等相關(guān)數(shù)據(jù)。

db.stats();

2、查看數(shù)據(jù)庫的統(tǒng)計信息

說明：通過此命令，可以查看操作數(shù)量、內(nèi)存使用狀況、網(wǎng)絡(luò)io等

db.runCommand( { serverStatus: 1 } )；

3、檢查復(fù)制集成員狀態(tài)

rs.status()；

三、基本的運維操作

1、設(shè)置和查看慢查詢

# 設(shè)置慢查詢
db.setProfilingLevel(1,200);
# 查看慢查詢級別
db.getProfilingLevel();
# 查詢慢查詢?nèi)罩?，此命令是針對于某一庫進行設(shè)置
db.system.profile.find({ ns : 'dbName.collectionName'}).limit(10).sort( { ts : -1 } ).pretty();

2、查看執(zhí)行操作時間較長的動作

db.currentOp({"active" : true,"secs_running" : { "$gt" : 2000 }});

3、動態(tài)調(diào)整日志級別和設(shè)置緩存大小

# 設(shè)置日志級別參數(shù)
db.adminCommand( { "getParameter": 1, "logLevel":1});
# 設(shè)置cache大小參數(shù)
db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=4G"});

4、添加和移除復(fù)制集成員

# 查看復(fù)制集成員
rs.status().members;
# 添加成員
rs.add('127.0.0.1:20001')；
# 移除成員
rs.remove('127.0.0.1:20001')；

5、設(shè)置數(shù)據(jù)庫和集合分片

# 在mongos admin庫設(shè)置庫允許分片
sh.enableSharding("dbName");
# 在mongos 的admin庫設(shè)置集合分片片鍵
sh.shardCollection("dbName.collectionName", { filedName: 1} );

6、添加和移除分片

# 查看分片狀態(tài)
sh.status()；
# 在mongos執(zhí)行添加分片（可以為單個實例或復(fù)制集）
db.runCommand( { removeShard: "shardName" } )；
db.runCommand({addshard:"rs1/ip-1:20001,ip-2:20001,ip-3:20001"});
# 在mongos執(zhí)行移除分片
db.runCommand( { removeShard: "shard3" } )；
# 在mongos執(zhí)行刷新mongos配置信息
db.runCommand("flushRouterConfig"))；

說明：移除分片命令至少執(zhí)行兩次才能成功刪除，執(zhí)行到state為completed才真正刪除，否則就是沒用刪除成功，該分片處于{"draining" : true}狀態(tài)，該狀態(tài)下不但該分片沒用刪除成功，而且還影響接下來刪除其他分片操作，遇到該狀態(tài)再執(zhí)行一次removeshard即可，最好就是刪除分片時一直重復(fù)執(zhí)行刪除命令，直到state為completed；   還有一個需要注意的地方就是：被成功刪除的分片如果想要再加入集群時，必須將data數(shù)據(jù)目錄清理干凈才可以再加入集群，否則即使能加入成功也不會存儲數(shù)據(jù)，集合都不會被創(chuàng)建   另外：在刪除分片的時有可能整個過程出現(xiàn)無限{"draining" : true}狀態(tài)，等多久還是這樣，而且分片上面的塊一個都沒有移動到別的分片，解決辦法是：在config的config數(shù)據(jù)庫的shard集合中找到該分片的信息，并將draining字段由True改為False,再繼續(xù)試著刪除操作”   上面這句會立即返回，實際在后臺執(zhí)行。  在數(shù)據(jù)移除的過程當中，一定要注意實例的日志信息，可能出現(xiàn)數(shù)據(jù)塊在遷移的過程中，始終找不到邊界條件，導(dǎo)致一直數(shù)據(jù)遷移不成功，一直重試，解決方案是刪除邊界數(shù)據(jù)，重啟實例；。如果此分片為主分片，需要先遷移主分片。db.runCommand( { movePrimary: "XXX", to: "other" })；在完成刪除后，所有mongos上運行下面命令，再對外提供服務(wù)，當然也可以重新啟動所有mongos實例 。

7、數(shù)據(jù)的導(dǎo)入導(dǎo)出

# 導(dǎo)出允許指定導(dǎo)出條件和字段
mongoexport -h 127.0.0.1 --port 20001 -uxxx -pxxx -d xxx -c mobileIndex -o XXX.txt 
mongoimport -h 127.0.0.1 --port 20001 -uxxx -pxxx -d xxx -c mobileIndex --file XXX.txt

四、MongoDB數(shù)據(jù)遷移

1、遷移復(fù)制集當中的成員

• 關(guān)閉 mongod 實例,為了確保安全關(guān)閉,使用 shutdown 命令；
• 將數(shù)據(jù)目錄(即 dbPath )轉(zhuǎn)移到新機器上；
• 在新機器上啟動 mongod，其中節(jié)點的數(shù)據(jù)目錄為copy的文件目錄 ；
• 連接到復(fù)制集當前的主節(jié)點上；

如果新節(jié)點的地址發(fā)生變化,使用 rs.reconfig() 更新 復(fù)制集配置文檔 ； 舉例,下面的命令過程將成員中位于第 2 位的地址進行更新:

cfg = rs.conf()
cfg.members[2].host = "127.0.0.1:27017"
rs.reconfig(cfg)

使用 rs.conf() 確認使用了新的配置. 等待所有成員恢復(fù)正常,使用 rs.status() 檢測成員狀態(tài)。

2、遷移復(fù)制集主節(jié)點

在遷移主節(jié)點的時候,需要復(fù)制集選舉出一個新的主節(jié)點,在進行選舉的時候,復(fù)制集將讀寫,通常,這只會持續(xù)很短的時間,不過,應(yīng)該盡可能在影響較小的時間段內(nèi)遷移主節(jié)點.

• 主節(jié)點降級,以使得正常的 failover開始.要將主節(jié)點降級,連接到一個主節(jié)點,使用 replSetStepDown方法或者使用rs.stepDown()方法,下面的例子使用了 rs.stepDown()方法進行降級:

rs.stepDown()

• 等主節(jié)點降級為從節(jié)點,另一個成員成為 PRIMARY 之后,可以按照 “遷移復(fù)制集的一個成員”遷移這個降級了的節(jié)點.可以使用 rs.status()來確認狀態(tài)的改變。

3、從復(fù)制集其他節(jié)點恢復(fù)數(shù)據(jù)

MongoDB 通過復(fù)制集能保證高可靠的數(shù)據(jù)存儲，通常生產(chǎn)環(huán)境建議使用「3節(jié)點復(fù)制集」，這樣即使其中一個節(jié)點崩潰了無法啟動，我們可以直接將其數(shù)據(jù)清掉，重新啟動后，以全新的 Secondary 節(jié)點加入復(fù)制集，或者是將其他節(jié)點的數(shù)據(jù)復(fù)制過來，重新啟動節(jié)點，它會自動的同步數(shù)據(jù)，這樣也就達到了恢復(fù)數(shù)據(jù)的目的。

• 關(guān)閉需要數(shù)據(jù)同步的節(jié)點

docker stop node;  # docker環(huán)境中
db.shutdownServer({timeoutSecs: 60}); # 非docker環(huán)境

• 拷貝目標節(jié)點機器的數(shù)據(jù)存儲目錄(/dbPath)到當前機器的指定目錄。

scp 目標節(jié)點 shard/data -> 當前節(jié)點 shard/data

• 當前節(jié)點以復(fù)制過來的數(shù)據(jù)文件啟動節(jié)點
• 將新的節(jié)點添加到復(fù)制集

# 進入復(fù)制集的主節(jié)點，執(zhí)行添加新的節(jié)點命令
rs.add("hostNameNew:portNew"); 
# 等待所有成員恢復(fù)正常,檢測成員狀態(tài)
rs.status();
# 移除原來的節(jié)點
rs.remove("hostNameOld>:portOld"); 

五、MongoDB線上問題場景解決

1、MongoDB 新建索引導(dǎo)致庫被鎖

問題說明：某線上千萬級別集合，為優(yōu)化業(yè)務(wù)，直接執(zhí)行新建索引命令，導(dǎo)致整個庫被鎖，應(yīng)用服務(wù)出現(xiàn)不可用。

解決方案：找出此操作進程，并且殺死。改為后臺新建索引，速度很會慢，但是不會影響業(yè)務(wù)，該索引只會在新建完成之后，才會生效；

# 查詢運行時間超過200ms操作     
db.currentOp({"active" : true,"secs_running" : { "$gt" : 2000 }}) ；
# 殺死執(zhí)行時間過長操作操作
db.killOp(opid)
# 后臺新建索引
db.collectionNmae.ensureIndex({filedName:1}, {background:true});

2、MongoDB沒有限制內(nèi)存，導(dǎo)致實例退出

問題說明：生產(chǎn)環(huán)境某臺機器啟動多個mongod實例，運行一段時間過后，進程莫名被殺死；

解決方案：現(xiàn)在MongoDB使用WiredTiger作為默認存儲引擎，MongoDB同時使用WiredTiger內(nèi)部緩存和文件系統(tǒng)緩存。從3.4開始，WiredTiger內(nèi)部緩存默認使用較大的一個：50％（RAM - 1 GB），或256 MB。 例如，在總共4GB RAM的系統(tǒng)上，WiredTiger緩存將使用1.5GB的RAM（）。相反，具有總共1.25 GB RAM的系統(tǒng)將為WiredTiger緩存分配256 MB，因為這超過總RAM的一半減去1千兆字節(jié)（）。0.5 * (4 GB - 1GB) = 1.5 GB``0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB。如果一臺機器存在多個實例，在內(nèi)存不足的情景在，操作系統(tǒng)會殺死部分進程；

# 要調(diào)整WiredTiger內(nèi)部緩存的大小，調(diào)節(jié)cache規(guī)模不需要重啟服務(wù)，我們可以動態(tài)調(diào)整：
db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=xxG"})

3、MongoDB刪除數(shù)據(jù)，不釋放磁盤空間

問題說明：在刪除大量數(shù)據(jù)(本人操作的數(shù)據(jù)量在2000萬+)的情景下，并且在生產(chǎn)環(huán)境中請求量較大，此時機器的cpu負載會顯得很高，甚至機器卡頓無法操作，這樣的操作應(yīng)該謹慎分批量操作；在刪除命令執(zhí)行結(jié)束之后，發(fā)現(xiàn)磁盤的數(shù)據(jù)量大小并沒有改變。

解決方案：

• 方案一：我們可以使用MongoDB提供的在線數(shù)據(jù)收縮的功能，通過Compact命令db.collectionName.runCommand("compact")進行Collection級別的數(shù)據(jù)收縮，去除集合所在文件碎片。此命令是以O(shè)nline的方式提供收縮，收縮的同時會影響到線上的服務(wù)。為了解決這個問題，可以先在從節(jié)點執(zhí)行磁盤整理命令，操作結(jié)束后，再切換主節(jié)點，將原來的主節(jié)點變?yōu)閺墓?jié)點，重新執(zhí)行Compact命令即可。

• 方案二：使用從節(jié)點重新同步，secondary節(jié)點重同步，刪除secondary節(jié)點中指定數(shù)據(jù)，使之與primary重新開始數(shù)據(jù)同步。當副本集成員數(shù)據(jù)太過陳舊，也可以使用重新同步。數(shù)據(jù)的重新同步與直接復(fù)制數(shù)據(jù)文件不同，MongoDB會只同步數(shù)據(jù)，因此重同步完成后的數(shù)據(jù)文件是沒有空集合的，以此實現(xiàn)了磁盤空間的回收。

  針對一些特殊情況，不能下線secondary節(jié)點的，可以新增一個節(jié)點到副本集中，然后secondary就自動開始數(shù)據(jù)的同步了?？偟膩碚f，重同步的方法是比較好的，第一基本不會阻塞副本集的讀寫，第二消耗的時間相對前兩種比較短。

1. 若是primary節(jié)點，先強制將之變?yōu)閟econdary節(jié)點，否則跳過此步驟：rs.stepdown(120)；
2. 然后在primary上刪除secondary節(jié)點：rs.remove("IP:port");
3. 刪除secondary節(jié)點dbpath下的所有文件
4. 將節(jié)點重新加入集群，然后使之自動進行數(shù)據(jù)的同步：rs.add("IP:port");
5. 等數(shù)據(jù)同步完成后，循環(huán)1-4的步驟可以將集群中所有節(jié)點的磁盤空間釋放

4、MongoDB機器負載極高

問題說明：此情景是在客戶請求較大的情景性，由于部署MongoDB的機器包含一主一從，MongoDB使得IO100%，數(shù)據(jù)庫阻塞，出現(xiàn)大量慢查詢，進而導(dǎo)致機器負載極高，應(yīng)用服務(wù)完全不可用。

解決方案：在沒有機器及時擴容的狀況下，首要任務(wù)便是減小機器的IO，在一臺機器出現(xiàn)一主一從，在大量數(shù)據(jù)寫入的情況下，會互相搶占IO資源。于是此時摒棄了MongoDB高可用的特點，摘掉了復(fù)制集當中的從節(jié)點，保證每臺機器只有一個節(jié)點可以占用磁盤資源。之后，機器負載立馬下來，服務(wù)變?yōu)檎？捎脿顟B(tài)，但是此時MongoDB無法保證數(shù)據(jù)的完整性，一旦有主節(jié)點掛掉便會丟失數(shù)據(jù)。此方案只是臨時方法，根本解決是可以增加機器的內(nèi)存、使用固態(tài)硬盤，或者采用增加分片集來減少單個機器的讀寫壓力。

# 進入主節(jié)點，執(zhí)行移除成員的命令
rs.remove("127.0.0.1:20001");
# 注意：切勿直接關(guān)停實例

5、MongoDB分片鍵選擇不當導(dǎo)致熱讀熱寫

問題說明：生產(chǎn)環(huán)境中，某一集合的片鍵使用了與_id生成方式相似，含有時間序列的字段作為升序片鍵，導(dǎo)致數(shù)據(jù)寫入時都在一個數(shù)據(jù)塊，隨著數(shù)據(jù)量增大，會造成數(shù)據(jù)遷移到前面的分區(qū)，造成系統(tǒng)資源的占用，偶爾出現(xiàn)慢查詢。

解決方案：臨時方案設(shè)置數(shù)據(jù)遷移的窗口，放在在正常的時間區(qū)段，對業(yè)務(wù)造成影響。根本解決是更換片鍵。

# 連接mongos實例，執(zhí)行以下命令
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop : "4:00" } } }, true )；
# 查看均衡窗口
sh.getBalancerWindow()；

六、MongoDB優(yōu)化建議

1、應(yīng)用層面優(yōu)化

查詢優(yōu)化：確認你的查詢是否充分利用到了索引，用explain命令查看一下查詢執(zhí)行的情況，添加必要的索引，避免掃表操作。

合理設(shè)計分片鍵：增量sharding-key：適合于可劃分范圍的字段，比如integer、float、date類型的，查詢時比較快。隨機sharding-key: 適用于寫操作頻繁的場景，而這種情況下如果在一個shard上進行會使得這個shard負載比其他高，不夠均衡，故而希望能hash查詢key，將寫分布在多個shard上進行,考慮復(fù)合key作為sharding key， 總的原則是查詢快，盡量減少跨shard查詢，balance均衡次數(shù)少；單一遞增的sharding key，可能會造成寫數(shù)據(jù)全部在最后一片上，最后一片的寫壓力增大，數(shù)據(jù)量增大，會造成數(shù)據(jù)遷移到前面的分區(qū)。MongoDB默認是單條記錄16M，尤其在使用GFS的時候，一定要注意shrading-key的設(shè)計。不合理的sharding-key會出現(xiàn)，多個文檔，在一個chunks上，同時，因為GFS中存貯的往往是大文件，導(dǎo)致MongoDB在做balance的時候無法通過sharding-key來把這多個文檔分開到不同的shard上， 這時候MongoDB會不斷報錯最后導(dǎo)致MongoDB倒掉。解決辦法：加大chunks大小（治標），設(shè)計合理的sharding-key（治本）。

通過profile來監(jiān)控數(shù)據(jù)：進行優(yōu)化查看當前是否開啟profile功能 用命令db.getProfilingLevel() 返回level等級，值為0|1|2，分別代表意思：0代表關(guān)閉，1代表記錄慢命令，2代表全部。開啟profile功能命令為 db.setProfilingLevel(level); #level等級，值level為1的時候，慢命令默認值為100ms，更改為db.setProfilingLevel(level,slowms)如db.setProfilingLevel(1,50)這樣就更改為50毫秒通過db.system.profile.find() 查看當前的監(jiān)控日志。

2、硬件層面優(yōu)化

2.1 確定熱數(shù)據(jù)大?。嚎赡苣愕臄?shù)據(jù)集非常大，但是這并不那么重要，重要的是你的熱數(shù)據(jù)集有多大，你經(jīng)常訪問的數(shù)據(jù)有多大(包括經(jīng)常訪問的數(shù)據(jù)和所有索引數(shù)據(jù))。使用MongoDB，你最好保證你的熱數(shù)據(jù)在你機器的內(nèi)存大小之下，保證內(nèi)存能容納所有熱數(shù)據(jù)； 2.2 選擇正確的文件系統(tǒng)：MongoDB的數(shù)據(jù)文件是采用的預(yù)分配模式，并且在Replication里面，Master和Replica Sets的非Arbiter節(jié)點都是會預(yù)先創(chuàng)建足夠的空文件用以存儲操作日志。這些文件分配操作在一些文件系統(tǒng)上可能會非常慢，導(dǎo)致進程被Block。所以我們應(yīng)該選擇那些空間分配快速的文件系統(tǒng)。這里的結(jié)論是盡量不要用ext3，用ext4或xfs；

3、架構(gòu)上的優(yōu)化

盡可能讓主從節(jié)點分攤在不同的機器上，避免IO操作的與MongoDB在同一臺機器；

七、總結(jié)

MongoDB具有高性能、易擴展、易上手等特點，在正確使用的情況下，其本身性能還是非常強悍，在一些關(guān)鍵點如片鍵的選擇、內(nèi)存的大小和磁盤IO，往往是限制其性能的最大瓶頸。針對于片鍵，在業(yè)務(wù)系統(tǒng)初期，可以先不對集合進行數(shù)據(jù)分片，因為分片鍵一旦確定就無法修改，后期可根據(jù)業(yè)務(wù)系統(tǒng)的情況，認真篩選字段。一般情況下，不建議使用升序片鍵（是一種隨著時間穩(wěn)定增長的字段,自增長的主鍵是升序鍵 ），因為這個會導(dǎo)致局部的熱讀熱寫，不能發(fā)揮分片集群的真正實力。建議使用hash片鍵或者隨機分發(fā)的片鍵，這樣可以保證數(shù)據(jù)的均勻分發(fā)在分片節(jié)點；針對于內(nèi)存，建議內(nèi)存的大小能夠包含熱數(shù)據(jù)的大小加索引大小，保證內(nèi)存能容納所有熱數(shù)據(jù) 。針對于磁盤資源，MongoDB的高速讀寫是以磁盤的IO作為基礎(chǔ)，為了保證其性能，建議將主從節(jié)點以及高IO的應(yīng)用分離，以保證IO資源盡可能不存在搶占。