mongdb集羣的搭建和常見問題

副本集要點:
mongodb

在利用副本集時最好不要設置用戶名和密碼,由於這樣會影響效率的,權限系統,很是耗資源,須要大量的運算。
服務器

一、爲了防止在選舉primary過程當中出現腦裂狀態(break ties),全部節點個數(包括仲裁者arbiter)爲奇數
網絡

二、可使用內網app

cfg = {_id : "myset",members : [ide

{ _id : 0, host : "192.168.86.88:27001" },優化

{ _id : 1, host : "10.100.20.189:27001" },ui

{ _id : 2, host : "192.168.86.129:27001",arbiterOnly : true } ] }spa

rs.initiate(cfg).net

或者
code

cfg = {_id : "myset",members : [{ _id : 0, host : "220.181.8.67:27001" }] }

rs.initiate(cfg)

rs.add("61.135.251.189:27001")

rs.addArb("220.181.8.129:27001")

上面方法的不足:每次重啓全部機器以後只有等到原來主庫重啓set才能正常工做

三、幾個關鍵狀態:UP、STARTUP二、RECOVERING、ARBITER、SECONDARY、DOWN

四、app經過客戶端驅動鏈接副本集,須要指定host列表,能夠不包括所有members,指定的member會將primary告訴給驅動

五、rs.slaveOk()  容許在secondary上讀數據

六、走索引的寫區別不大,3300req/s(set) vs 4000res/s(single)

七、當超過一半(包括一半)的機器掛掉以後會有,全部正常節點的pov小於或等於cfg機器的一半,set不在提供服務,正常節點(包括primay)變成secondary,

[rsMgr] can't see a majority of the set, relinquishing primary

[rsMgr] replSet relinquishing primary state

[rsMgr] replSet SECONDARY

八、當一個鏈接在操做mongodb時出現primary的切換會致使異常:

pymongo.errors.AutoReconnect: [Errno 10054] 

九、激活切片以前全部的數據寫入都會指向同一個切片;

enablesharding,shardcollection 進行切片設置的時候,若是表的數據不爲空,那麼shard key必須有索引方能切片,若是表的數據爲空,自動建立索引

十、A chunk is a range on the shard key 一個chunk定義並存儲了一個shard key的範圍值,是collection, minKey, and maxKey的三元組;

當一個chunk的大小超過了最大值(默認64M),會分裂爲兩個chunk,但若是一個chunk裏的key值都是一個值,這個chunk將是不可分割的,而且肯可能會愈來愈大,出現這種狀況每每說明shard key須要改進

當一個切片的數據過大,其chunk會在切片內部發生遷移;

新增切片一樣會影響chunk在切片內部的遷移

十一、如何選擇shard key

http://blog.csdn.net/zhangzhaokun/article/details/6324389 

Cardinality(基數):shard key 粒度得細  一個key的粒度不夠能夠考慮多個組合

Write scaling(寫分散):爲了將寫操做盡可能分佈到更多的chunk中去

Query isolation(查詢隔離):將讀操做盡量的集中在更少的chunk中

Reliability:當一個切片掛掉,但願影響範圍控制到最小,跟業務相關,好比一個用戶可能有多種屬性,若是以某個屬性爲key,那麼若是一個切片掛掉,全部用戶都受影響

Index optimization:索引優化,可將多個value組合在一塊兒作爲一個更利於分片的key

GridFS

十二、每一個Config DB上都有一份cluster's metadata的拷貝,他們之間用two-phase commit(2PC)來保證一致性;

任何一個config db掛掉都會致使cluster's metadata  goes read only,及時這樣,不影響mongodb集羣的寫入和讀出

1三、mongos之間沒有協做關係,config db上任何一個修改都會 propagated to 全部mongos

mongos自己不持久化,是無狀態的,每次啓動從config db上加載狀態

1四、系統時間的保證同步,不然mongos在balance時會出現問題,例如

caught exception while doing balance: error checking clock skew of cluster 192.168.51.65:20000,10.100.20.50:20000,10.100.20.54:20000 :: caused by :: 13650 clock skew of the cluster 192.168.51.65:20000,10.100.20.50:20000,10.100.20.54:20000 is too far out of bounds to allow distributed locking.

修正時間以後

creating distributed lock ping thread for 192.168.51.65:20000,10.100.20.50:20000,10.100.20.54:20000 and process zw29-65:30000:1336983072:1804289383 (sleeping for 30000ms)

1五、db.adminCommand({replSetGetStatus:1})

db.adminCommand({replSetSyncFrom:"otherHost:27017"})

1六、關於replication set 選舉:

節點類型:主動節點、被動節點(優先級爲0,只投票、有備份)、arbiter節點

心跳:set裏各節點會想全部其餘發送心跳報告本身的狀態(角色+同步時間+優先級等等)

選舉:節點在更新個節點心跳狀態的同時,會判斷

primary:若是有節點故障,判斷本身是否有必要降級,若是本身可達的節點數據少於一半,自動降級爲secondary,避免出現本身被網絡隔離而不放棄primary地位

secondary:判斷又不必升級爲primary,若是本身知足成爲primary的資格(優先級最高,數據最新),而set裏沒有其餘的primary,則向其餘的節點發起詢問,其餘節點判斷若是該節點確實知足此條件,則表示容許發起投票,不然告之中止投票;當全部其餘節點表示能夠投票的狀況下,節點發起接管primary的投票,其餘節點再次確認,投同意票和反對票,最後選舉結果依據一票否決和多數經過的原則來判斷是否當選primary,注意一點一個節點投出同意票以後30s以內不能再進行其餘的投票決定。


============================== mongo 切片集羣上的操做 =====================

一、pymongo.errors.OperationFailure: Can't modify shard key's value fieldcode for collection: hktest.hkstocks

不能修改shared field的值

二、特別注意manipulate選項 insert默認爲true,update默認爲false,insert一個對象的時候,若是manipulate選項爲true,驅動會添加_id屬性並返回,不然id由服務器負責生成,帶來的問題就是重複insert這個對象時,會致使重複id的插入,即便對象的其餘屬性發生變化。

三、update一個記錄的時候,set的對象不能包含shared key的值,由於一條記錄的shared key是不能夠發生改變的

pymongo.errors.OperationFailure: Can't modify shard key's value fieldcode for collection: hktest.hkstocks

四、在mongodb set 中primary的oplogsize應該足夠大,不然在導入數據的時候可能致使secondary too stale

五、對於一個已有數據的mongod想成爲切片直接經過db.adminCommand( { addShard : "host:port" } ),不過切片即爲他本身的庫裏的primary shard

六、使用一個已存在的unique索引進行切片時出現 "errmsg" : "exception: invalid parameter: expected an object ()";多是存在沒有片建的記錄,刪除便可

七、不能使用dropcollection刪除表數據,不然要從新建分片

八、config出現不一致的狀況時  db.adminCommand( "flushRouterConfig" )


=============================== 單機上雙切片帶來的問題 ====================

一、chunk的誇切片移動會帶來很大的網絡負擔和io負擔

二、批量操做會有很大的io操做,好比刪除清理一個表

相關文章
相關標籤/搜索