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 Count：
TCP 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();
NUMA：
Linu,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
注意：在MongoDB中要用IP地址不要使用機器名或localhost，不然會出現鏈接不數據庫的。
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是支持回滾恢復。
journaling的時候，stop m ongod ,clone, and tehn restart
注意：在MongoDB中要用IP地址不要使用機器名或localhost，不然會出現鏈接不數據庫的。
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的數據刪掉 ，啓動。數據會自動兩步上去的。