一、副本集

1.復(fù)制

一個mongod服務(wù)器掛了就完了，使用復(fù)制可以把數(shù)據(jù)副本保存在多臺服務(wù)器。在MongoDB里，創(chuàng)建一個副本集就可以使用復(fù)制功能。副本集是一組服務(wù)器，主服務(wù)器用來處理客戶端請求，備份服務(wù)器用來保存主服務(wù)器的數(shù)據(jù)副本，如果主服務(wù)器崩了，備份服務(wù)器會自動把一個成員升級成主。

2.建立副本集

mongo --nodb                                //啟動mongo shell，但不連接到任何mongod
replicaSet  = new ReplSetTest({"nodes":3})  //創(chuàng)建3個節(jié)點的副本集
replicaSet.startSet()                       //啟動3個mongod進(jìn)程
replicaSet.initiate()                       //配置復(fù)制功能

現(xiàn)在有三個mongod進(jìn)程，分別運行在31000，31001，31002

conn1 = new Mongo("localhost:31000")        //連接運行在31000的mongod。

提示符變成testReplSet：primary，說明連上了主節(jié)點。
備份節(jié)點的數(shù)據(jù)可能會落后于主節(jié)點，所以如果在備份節(jié)點上做查詢，可能會得到錯誤提示，說當(dāng)前不是主節(jié)點。這樣做為了保護(hù)應(yīng)用程序，以免連接到備份節(jié)點讀到過期數(shù)據(jù)。如果你非要允許從備份節(jié)點讀：conn2.slaveOk()。這個語句是為conn2這個連接設(shè)置的，而不是這個庫。

而且，備份節(jié)點不能執(zhí)行寫操作，它只通過復(fù)制功能寫入數(shù)據(jù)。副本集也支持自動故障轉(zhuǎn)移，主節(jié)點掛了后，第一個檢測到它掛了的節(jié)點可以成為新的主節(jié)點。

primaryDB.adminCommand({"shutdown":1})  //關(guān)掉主節(jié)點
secondaryDB.isMaster()                  //上從節(jié)點執(zhí)行下看看誰是新的主節(jié)點。

3.副本集的組成

1.同步
復(fù)制是用于在多臺服務(wù)器之間備份數(shù)據(jù)，復(fù)制功能是使用操作日志oplog實現(xiàn)，操作日志包含主節(jié)點的每一次寫操作。每個備份節(jié)點都維護(hù)著自己的oplog，記錄著每一次從主節(jié)點復(fù)制數(shù)據(jù)的操作。
如果備份節(jié)點掛掉了，下次恢復(fù)的時候再從最后一個oplog開始同步，如果oplog有重復(fù)也沒有關(guān)系，oplog中的操作執(zhí)行一次和執(zhí)行多次是一樣的，但也要保證順序。
對于同步，副本集剛開始是要做初始化同步，在這個時間段內(nèi)是不可以成為正常的副本的，只有初始化完成了才可以進(jìn)入普通同步狀態(tài)，初始化同步就是選一個副本把oplog復(fù)制過來。
2.心跳
為了維護(hù)副本的最新視圖，每隔2s每個成員就會向其他成員發(fā)送心跳。他們需要知道誰是主節(jié)點，誰掛掉了，誰可以是同步源。
3.選舉
當(dāng)一個成員無法連接到主節(jié)點，就發(fā)起成為主節(jié)點的請求給他能連接到的所有節(jié)點。

二、分片

1.什么時候需要分片？

當(dāng)一個單機(jī)的存儲容量無法支撐的時候，可以用分片做水平擴(kuò)容；還有一種就是單機(jī)qps扛不住，可以把請求分散到多個分片上去。

2. 分片集群都包含什么？

多個mongos，多個config server，多個分片。
mongos負(fù)責(zé)接收client請求，然后去config server去找數(shù)據(jù)所在的位置，再去某一個分片請求數(shù)據(jù)，返回給client。
mongos的存在提供了一種單點連集群的方式，看起來和單點一樣，讓用戶對分片無感知，mongos是沒有持久化的，所以不保存任何配置信息。config server存儲集群元數(shù)據(jù)，包含全局集群的配置信息，每個數(shù)據(jù)庫集合、特定數(shù)據(jù)的范圍的位置，以及保存了跨片數(shù)據(jù)遷移歷史的一個修改日志。配置服務(wù)器不是可復(fù)制集群，它們需要比異步復(fù)制更強大的東西，當(dāng)mongos進(jìn)程寫入它們時，使用的是兩端提交協(xié)議。而且，必須在分片集群生產(chǎn)環(huán)境下部署3太配置服務(wù)器，而且必須部署在單獨的冗余機(jī)器上。

3.分片中的數(shù)據(jù)

分片中的數(shù)據(jù)是以chunk為單位，一個chunk中可能包含多個document，它是根據(jù)分片健分出來的，所以，mongo的分區(qū)是基于collection的，從一個集合里面選擇部分文檔組合成一個chunk，這就相當(dāng)于mysql從一個表里面選擇幾行作為一塊。
下面就說一下，mongoDB自動分片，自動分片說的是給單個集合分片，不需要應(yīng)用參與。就為了分片單個集合，定義出了塊的概念，它是一個分片健的邏輯分組文檔。

4. MongoDB自動分片

MongoDB分片是基于范圍的，也就是每個塊表示一個范圍的健值。比如你先在有個文檔有個age字段，然后你用age做分片鍵值（正常不太可能），分片有A和B兩個。你分出來可能這樣：
開始-------結(jié)束---片
負(fù)無窮-----10-----A
10-----------20-----B
20-----------30-----A
30-----------40-----B
這樣就可以確定文檔所屬的塊，然后決定它應(yīng)該被發(fā)到哪個分片。
雖然分片是自動的，但前提是你要在數(shù)據(jù)庫里提前為集合做好設(shè)置開啟才行。

5.分割與遷移

你把數(shù)據(jù)存儲到mongo上，它會自動按照分片健做把document分到不同的chunk，但是如果有的chunk是有大小限制的，如果10-20的數(shù)據(jù)太多了，chunk超出閾值了怎么辦？就要分割了。那么遷移，就是說，可能各個分片之間，數(shù)據(jù)不均衡，很多chunk集中在一個分片上，那么分片之間就要做遷移了。

6. 分片集群中的查詢

雖然對于用戶來說mongo分不分片，用起來都是一樣的，但實際執(zhí)行起來肯定是不同的，下面看一下使用了分片的mongo是怎么查詢的。
首先，我要查的文檔可能是分布在多個分片，也可能是一個分片，那么我要求請求哪些分片呢？記住配置服務(wù)器維護(hù)了分片鍵值到分片服務(wù)器的信息，如果查詢語句包含片健，就能快速定位到分片，如果不包含片健，那完了，要遍歷所有分片了。

7. 分片中的索引

無論你插入定位的多么完美，其實，最終所有的數(shù)據(jù)都只是在一個分片上，如果你這個分片查的慢，整個集群都慢。
未分片模式下，索引是優(yōu)化查詢的手段。
關(guān)于分片集群的索引記住下面：每個分片維護(hù)自己的索引，它遵循分片集合在每個分片上都應(yīng)該建立相同的索引原則，分片集合只允許在_id字段和分片健上建立唯一索引。

8.分片健的選擇

如果你分片健選擇的不好，很多性能都會變得很差，而且你分片健一旦選擇，后面是不能修改的，選擇分片鍵可能出現(xiàn)的糟糕情況：
熱點 某些分片會造成數(shù)據(jù)都分在同一個chunk或者同一個分片上，所有流量還是打到一個分片上。
不可分割的數(shù)據(jù)塊 過于粗粒度的分片健導(dǎo)致許多文檔使用相同的分片健，這些文檔可能不能分散到不同的數(shù)據(jù)塊？？chunksize也不控制不了嗎？是的，比如你按照username做分片健，如果一個username直接插入了10GB數(shù)據(jù)，正常情況超過chuncksize會給你分，但如果你的分片健都是一樣的，它也沒辦法給你分了。

如果你按照objectId作為分片健，因為ObjectID完全自增，比如你插入了1000條文檔了，那你插入1001，1002，1003的時候，因為mongo根本沒有見過1000到maxKey之間的數(shù)字，它根本不知道怎么給你分，只能繼續(xù)插入，所以不管你怎么插入，都只會插在這一個分片里。你可以給ObjectID做一個hash，讓mongo用這個hash去分，雖然數(shù)據(jù)可以均勻的分布在不同的分片上，但是你做范圍查詢的時候可能就要去請求所有分片了。