MongoDB 常見問題處理
說明： 這裡的問題是我在看MongoDB官網文章時，從裡面總結出來的。
mongod process "disappeared" ：這個說的是mongodb進行消失，可以了解為死掉等。可以從下面中找問題在
#grep mongod /var/log/messages
#grep score /var/log/messages
Socket errors in sharded clusters and replica sets：
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time 預設是7200
關于tomm many open files:
First:檢查以下幾項：
lsof | grep mongod
lsof | grep mongod | grep TCP
lsof | grep mongod | grep data | wc
可以用：ulimit解決: ulimit -n X
High TCP Connection CountTCP Connection過大時，可以檢查是不是client apps使用連接配接池問題
Mongod (hard) connection limit
這個連接配接數限制在20000，可以手動調整大小
Data files count with very large databases
資料在T級以上時，确定是否做了限制（手動增加），再用repairdatabase時，會同時有2 copies
No space left on device
這個時候reads仍然在進行，要做的是first shutdown servers, then to delete some data and compact
Checking Siez of a collection(檢查集合）
>db.(collectionname).validate();
NUMALinu,Numa and MongoDB不能很好的一起工作。如果機器在numa硬體運作的時候，需要把它關閉。一般出現大規模性能慢下來或一段時間cpu占用很高的system time 。可以從日志中抓取NUMA字。（我也翻譯不出這個NUMA是什麼意思）
關閉的方法：一：在啟動mongoDB的時候：
numactl --interleave=all ${MONGODB_HOME}/bin/mongod --config conf/mongodb.conf
二：在不關閉mongoDB時：
echo 0 > /proc/sys/vm/zone_reclaim_mod
案例：http://blog.csdn.net/weiyuanke/article/details/7639915或http://huoding.com/2011/08/09/104 或http://www.ttlsa.com/html/1211.html
NFS： 官網不建意采用NFS系統檔案運作mongoDB,因為NFS版本問題會導緻性能很低或無法工作 SSD mongoDB在SSD（固态硬碟）運作很快，但是比RAM低。可以用mongoperf進行硬碟性能狀态分析。 Virtualization：mongoDB在虛拟化上運作的很好，如OpenVZ 相容EC2 ，VMWare也可以但是clone的時候會出現一些問題由其在a member of a replica set(一個複制節點上），要想可用的，需要journaling處在可用狀态，再進行clone。如果沒有的開啟journaling的時候，stop m ongod ,clone, and tehn restart
注意：在MongoDB中要用IP位址不要使用機器名或localhost，不然會出現連結不資料庫的。
Journal （日志）：日志的開啟：--journal ；關閉：--nojournal ,預設時間是100ms
啟動時會在資料目錄下建立一個journal地檔案目錄，在受到毀壞時，再啟動mongoDB不需要再運作repair，它會自動恢複的。
可以通過運作journalLatencyTest測試寫入磁盤的性能和同步性能。
>use admin
>db.runCommand("journalLatencyTest")
Backup with --journal 中journal是支援復原恢複。
journaling的時候，stop m ongod ,clone, and tehn restart
The Linux Out of Memory OOM Killer情況一：
Feb 13 04:33:23 hostm1 kernel: [279318.262555] mongod invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
這是因為記憶體溢出導緻mongodb程序被刹死
情況二：
内在沒有溢出，能過db..serverStatus()或mongostat檢視記憶體virtualbytes - mappedbytes的界限
情況三：
ulimit的限制
t:minor-latin; mso-fareast-font-family:宋體;mso-fareast-theme-font:minor-fareast;mso-hansi-font-family: Calibri;mso-hansi-theme-font:minor-latin'>中journal是支援復原恢複。
mongodb 占用空間過大的原因，在官方的 FAQ 中，提到有如下幾個方面：1、空間的預配置設定：為避免形成過多的硬碟碎片，mongodb每次空間不足時都會申請生成一大塊的硬碟空間，而且申請的量從64M、128M、256M那樣的指數遞增，直到2G為單個檔案的最大體積。随着資料量的增加，你可以在其資料目錄裡看到這些整塊生成容量不斷遞增的檔案。
2、字段名所占用的空間：為了保持每個記錄内的結構資訊用于查詢，mongodb需要把每個字段的key-value都以BSON的形式存儲，如果value域相對于key域并不大，比如存放數值型的資料，則資料的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些，這樣占用空間就小了，但這就要求在易讀性與空間占用上作為權衡了。我曾建議作者把字段名作個index，每個字段名用一個位元組表示，這樣就不用擔心字段名取多長了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到用戶端，這個替換也是挺耗費時間的。現在的實作算是拿空間來換取時間吧。
3、删除記錄不釋放空間：這很容易了解，為避免記錄删除後的資料的大規模挪動，原記錄空間不删除，隻标記“已删除”即可，以後還可以重複利用。
RepairDatabase 指令：資料庫總會出現問題的，關于修複的方法如下：
運作db.repairDatabase()來整理記錄，但這個過程會比較緩慢。
當MongoDB做的是副本叢集時：可以直接把資料rm掉，然後再重新啟動。
當在不是primariy server上運作時，會得到一個"clone failed for wkgbc with error: query failed wkgbc.system.namespaces"
解決方法： 為了修複，需要restart server 不加--replSet選項并且要選用不同的端口 LINUX 下找出哪個程序造成的 IO 等待很高的方法： 可以判斷是不是IO問題造成的：| #/etc/init.d/syslog stop #echo 1 > /proc/sys/vm/block_dump #dmesg |egrep "READ|WRITE|dirtied"|egrep -o '([a-zA-Z*])'|sort|uniq -c|sort -rn|head |
昨天我通路mongodb的python程式開始出錯，經常抛出AssertionError異常，經查證隻是master查詢異常，slave正常，可判斷為master的資料出了問題。
修複過程：
1、在master做db.repairDatabase()，不起作用； 這個時間很長
2、停止slave的同步；
3、對slave作mongodump，備份資料；
4、對master作mongostore，把備份資料恢複，使用–drop參數可以先把原表删除。
5、恢複slave的同步。
執行個體二：碎片整理-replSet架構
1、rs.freeze(60) 在60s内該機器無法成為primary
2、在primary機上進行rs.stepDown([120]) 讓該機器成為從節點且在120s内不會成為primary
3、在primary上 ，可以将data的資料删掉 ，啟動。資料會自動兩步上去的。
![DIV彈出式登入視窗[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)