mongoDB基礎架構(gòu)簡析

1、mongoDB基礎架構(gòu)簡析楊森2016年1月21日主從復制副本集分片這種配置只適合簡易開發(fā)時使用，生產(chǎn)使用不行，因為單節(jié)點掛掉整個數(shù)據(jù)業(yè)務全掛雖然不能生產(chǎn)使用，但這個模式可以快速搭建啟動，并且能夠用mongodb的命令操作數(shù)據(jù)庫。單實例使用mysql和oracle數(shù)據(jù)庫時廣泛用到，采用雙機備份后主節(jié)點掛掉了后從節(jié)點可以接替主機繼續(xù)服務。所以這種模式比單節(jié)點的高可用性要好很多。主從模式主從模式主從模式環(huán)境搭建主服務器配置從服務器配置主從模式原理在主從結(jié)構(gòu)中，主節(jié)點的操作記錄成為oplog（operation log）。oplog存儲在一個系統(tǒng)數(shù)據(jù)庫local的集合oplog.$main中，這個集

2、合的每個文檔都代表主節(jié)點上執(zhí)行的一個操作。db.oplog.$main.find().sort($natural:-1);Ts表示時間戳，op表示操作類型，ns表示操作的集合名，o表示具體操作的文檔主從復制原理這里需要要注意的是：存儲在oplog中的操作有時可能和主節(jié)點操作并不一致，因為存儲操作前要進行等冪變換，也就是這些操作必須可以再從服務器上多次執(zhí)行，只要順序一致，結(jié)果就一致。因此比如更新器$inc的操作，最后會被變換為$set操作這個集合中只會存儲影響數(shù)據(jù)的操作，查詢這類不影響數(shù)據(jù)的操作不會以oplog的形式進行存儲oplog的集合為MongoDB固定集合，隨著操作過多，新的操作會覆蓋舊

3、的操作在啟動服務時，可以通過選項-oplogSize來指定這個集合的大小，單位是MB默認MongoDB會使用數(shù)據(jù)庫安裝分區(qū)可用空間的5%作為這個集合的大小。為了安全起見，這個值，因設置的足夠大。主從復制啟動參數(shù)簡析參數(shù)適用范圍作用備注Onlyslave指定需要數(shù)據(jù)同步的數(shù)據(jù)庫slavedelayslave指定從服務器從主服務器上同步操作的延時時間這對于一些無意的刪除重要數(shù)據(jù)或插入垃圾數(shù)據(jù)有一定的防護作用，通過延時，可暫緩這些不良操作在從服務器上被執(zhí)行！僅僅是延時處理，在主服務器上的各種改變數(shù)據(jù)的操作最后都會在從服務器上被執(zhí)行fastsyncslave以主服務器節(jié)點的數(shù)據(jù)快照為基礎啟動從服務器節(jié)

4、點從服務節(jié)點啟動后，要先完整同步主服務節(jié)點上的數(shù)據(jù)，然后再獲取主服務節(jié)點的oplog來保持后續(xù)的同步。使用這個啟動參數(shù)，從服務器節(jié)點的啟動要比完整同步快很多！主從復制啟動參數(shù)簡析參數(shù)適用范圍作用備注autoresync slave如果從節(jié)點與主節(jié)點不同步了，則自動重新同步使用這個選項啟動從服務器，當從服務器停止同步時，會自動啟動重新完整同步操作。完整同步代價比較高，應盡量避免，較好的方式就是設置足夠大的oplog！如需手動完整同步，執(zhí)行db.runCommand(resync : 1)oplogSizemaster定放置oplog的集合所占據(jù)的空間大小默認的規(guī)則,磁盤分區(qū)剩余空間的5%,這個選

5、項可以優(yōu)于這個規(guī)則來顯示指定。主從復制添加及刪除源指定主節(jié)點的方式：啟動從節(jié)點時，直接通過source選項指定主節(jié)點,在從節(jié)點中，通過集合操作，動態(tài)的添加或者刪除主數(shù)據(jù)源在從節(jié)點中，放置主節(jié)點（這里可以稱為同步數(shù)據(jù)源）信息的集合為local.sources，插入的文檔鍵“host”指明主節(jié)點的ip和端口號，通過這種方式可以很靈活的指定或移除從節(jié)點的主節(jié)點信息。主從復制復制狀態(tài)所有從節(jié)點連接到主節(jié)點后都會執(zhí)行handshake命令進行握手，將自己添加到一個集合中，這個集合就是local數(shù)據(jù)庫的slaves因此，主節(jié)點的復制狀態(tài)包括從節(jié)點的集合。uselocalswitchedtodblocald

6、b.slaves.find();_id:ObjectId(56947a92ba4fc99c7c59afb6),host:192.168.86.129:27017,ns:local.oplog.$main,syncedTo:t:1452679903,i:1主節(jié)點復制狀態(tài)主從復制復制狀態(tài)從節(jié)點的復制狀態(tài)包括：在me集合中存放的從節(jié)點唯一標示符；在sources集合中存放的主節(jié)點（或稱數(shù)據(jù)源）列表uselocalswitchedtodblocalshowcollections;mesourcesstartup_logdb.me.find();_id:ObjectId(56947a92ba4fc99c

7、7c59afb6),host:ubuntudb.sources.find();_id:ObjectId(56947a94ba4fc99c7c59afb7),host:192.168.86.128:27017,source:main,syncedTo:Timestamp(1452679903,1)從節(jié)點復制狀態(tài)主從復制復制狀態(tài)我們可以看到，me集合中該文檔的鍵“_id”和主節(jié)點slaves集合對應的該從節(jié)點文檔的“_id”的值是一樣的！主節(jié)點的slaves集合和從節(jié)點的sources集合都有鍵“syncedTo”，主從節(jié)點都是通過這個鍵的值來跟蹤從節(jié)點的更新狀況！每次從節(jié)點查詢主節(jié)點的oplog

8、時，都會用“syncedTo”作為查詢條件來確認哪些操作需要執(zhí)行，或者查看是否已經(jīng)跟不上同步了！從節(jié)點復制狀態(tài)主從復制確保數(shù)據(jù)同步進行數(shù)據(jù)庫管理員可以通過在主節(jié)點上執(zhí)行getLastError命令的“w”參數(shù)來確保同步正在進行！db.runCommand(“getLastError” : 1, “w” : N)；運行這個命令會進入阻塞階段，直到“N”（“w”鍵的值）個服務器復制了最新的寫操作后返回！如果該命令的N rs.add(192.168.86.131:27117); /添加節(jié)點 repmore:PRIMARY rs.remove(192.168.86.131:27117); /刪除節(jié) 利

9、用利用rs.add和和rs.remove是不用是不用rs.reconfig來使用配置生效的。來使用配置生效的。副本集節(jié)點類型Master主節(jié)點(Master)Secondary副本節(jié)點(Slave或者稱為Secondary)arbiter仲裁節(jié)點不存儲數(shù)據(jù)，只是負責故障轉(zhuǎn)移的群體投票，一般是用來湊數(shù)，在機器充足的前情況下，無需使用Secondary-Only不能成為primary節(jié)點，只能作為secondary副本節(jié)點，防止一些性能不高的節(jié)點成為主節(jié)點。Hidden這類節(jié)點是不能夠被客戶端制定IP引用，也不能被設置為主節(jié)點，但是可以投票，一般用于備份數(shù)據(jù)。Delayed可以指定一個時間延遲從p

10、rimary節(jié)點同步數(shù)據(jù)。主要用于備份數(shù)據(jù)，如果實時同步，誤刪除數(shù)據(jù)馬上同步到從節(jié)點。所以延遲復制主要用于避免用戶錯誤。Non-Voting沒有選舉權(quán)的secondary節(jié)點，純粹的備份數(shù)據(jù)節(jié)點副本集節(jié)點類型隱藏節(jié)點隱藏節(jié)點(Hidden)：隱藏節(jié)點可以在選舉中投票，但是不能被客戶端引用，也不能成為主節(jié)點。也就是說這個節(jié)點不能用于讀寫分離的場景。除了投票功能外，還用于數(shù)據(jù)備份。只有優(yōu)先級為0的成員才能設置為隱藏節(jié)點，否則會報錯將192.168.86.130:20002設置為hidden節(jié)點后：cfg.members3.priority=0cfg.members3.hidden=1rs.reco

11、nfig(cfg);副本集節(jié)點類型設置仲裁節(jié)點設置仲裁節(jié)點：仲裁節(jié)點不存儲數(shù)據(jù)，只是用于投票。所以仲裁節(jié)點對于服務器負載很低。節(jié)點一旦以仲裁者的身份加入集群，他就只能是仲裁者，無法將仲裁者配置為非仲裁者，反之也是一樣。另外一個集群最多只能使用一個仲裁者，額外的仲裁者拖累選舉新Master節(jié)點的速度，同時也不能提供更好的數(shù)據(jù)安全性。config=_id:wechatRepset,members:_id:0,host:192.168.86.128:27117,_id:1,host:192.168.86.129:27117,_id:2,host:”192.168.86.130:27117”,arbi

12、terOnly:true使用仲裁者主要是因為MongoDB副本集需要奇數(shù)成員，而又沒有足夠服務器的情況。在服務器充足的情況下，不應該使用仲裁者節(jié)點。副本集節(jié)點類型設置設置延遲復制節(jié)點延遲復制節(jié)點：延遲節(jié)點的優(yōu)先級必須為0，這個和hidden節(jié)點是一樣的。設置192.168.86.129為延遲節(jié)點cfg=rs.conf();cfg.members1.priority=0cfg.members1.slaveDelay=3600rs.reconfig(cfg);slaveDelay的單位是秒延遲復制，可用于故障恢復時使用副本集節(jié)點類型延遲節(jié)點延遲節(jié)點故障恢復模擬故障恢復模擬：副本集節(jié)點類型設置Sec

13、ondary-Only節(jié)點：Priority為0的節(jié)點永遠不能成為主節(jié)點，所以設置Secondary-only節(jié)點只需要將其priority設置為0.設置Non-Voting節(jié)點：不能投票,只能備份則cfg=rs.conf();cfg.members0.votes=0;rs.reconfig(cfg)副本集master選擇方式Bully選舉算法Bully算法是一種協(xié)調(diào)者（主節(jié)點）競選算法，主要思想是集群的每個成員都可以聲明它是主節(jié)點并通知其他節(jié)點。別的節(jié)點可以選擇接受這個聲稱或是拒絕并進入主節(jié)點競爭。被其他所有節(jié)點接受的節(jié)點才能成為主節(jié)點。節(jié)點按照一些屬性來判斷誰應該勝出。這個屬性可以是一個靜

14、態(tài)ID，也可以是更新的度量像最近一次事務ID（最新的節(jié)點會勝出） 副本集master選擇方式選舉過程大致如下：得到每個服務器節(jié)點的最后操作時間戳。每個mongodb都有oplog機制會記錄本機的操作，方便和主服務器進行對比數(shù)據(jù)是否同步還可以用于錯誤恢復。如果集群中大部分服務器down機了，保留活著的節(jié)點都為 secondary狀態(tài)并停止，不選舉了。如果集群中選舉出來的主節(jié)點或者所有從節(jié)點最后一次同步時間看起來很舊了，停止選舉等待人來操作。如果上面都沒有問題就選擇最后操作時間戳最新（保證數(shù)據(jù)是最新的）的服務器節(jié)點作為主節(jié)點。副本集master選擇方式選舉的觸發(fā)條件：初始化一個副本集時。副本集和主

15、節(jié)點斷開連接，可能是網(wǎng)絡問題。主節(jié)點掛掉。人為介入,比如修改節(jié)點優(yōu)先級等選舉還有個前提條件：參與選舉的節(jié)點數(shù)量必須大于副本集總節(jié)點數(shù)量的一半，如果已經(jīng)小于一半了所有節(jié)點保持只讀狀態(tài)。副本集主節(jié)點的讀寫壓力過大如何解決讀寫分離1、設置讀寫分離需要先在副本節(jié)點SECONDARY 設置 setSlaveOk。2、在程序中設置副本節(jié)點負責讀操副本集主節(jié)點的讀寫壓力過大如何解決primary:默認參數(shù)，只從主節(jié)點上進行讀取操作；primaryPreferred:大部分從主節(jié)點上讀取數(shù)據(jù),只有主節(jié)點不可用時從secondary節(jié)點讀取數(shù)據(jù)。secondary:只從secondary節(jié)點上進行讀取操作，存在

16、的問題是secondary節(jié)點的數(shù)據(jù)會比primary節(jié)點數(shù)據(jù)“舊”。secondaryPreferred:優(yōu)先從secondary節(jié)點進行讀取操作，secondary節(jié)點不可用時從主節(jié)點讀取數(shù)據(jù)；nearest:不管是主節(jié)點、secondary節(jié)點，從網(wǎng)絡延遲最低的節(jié)點上讀取數(shù)據(jù)。節(jié)點的讀寫壓力過大問題解決從節(jié)點每個上面的數(shù)據(jù)都是對數(shù)據(jù)庫全量拷貝，從節(jié)點壓力會不會過大？主從復制副本集分片分片在系統(tǒng)早期，數(shù)據(jù)量還小的時候不會引起太大的問題，但是隨著數(shù)據(jù)量持續(xù)增多，后續(xù)遲早會出現(xiàn)一臺機器硬件瓶頸問題的。在傳統(tǒng)數(shù)據(jù)庫中，如oracle、mysql等怎么做海量數(shù)據(jù)讀寫？分庫、分表分而治之mongod

17、b主打的就是海量數(shù)據(jù)架構(gòu)，如何解決海量數(shù)據(jù)？分片分片mysql要做到自動擴展需要加一個數(shù)據(jù)訪問層用程序去擴展，數(shù)據(jù)庫的增加、刪除、備份還需要程序去控制。一但數(shù)據(jù)庫的節(jié)點一多，要維護起來也是非常頭疼的。分片架構(gòu)面對mysql等數(shù)據(jù)庫給你帶來的煩惱，mongodb所有的這一切通過他自己的內(nèi)部機制就可以搞定。分片組成部分MongoDB分片系統(tǒng)通常由以下3部分組成：1 片： 片就是一個存放集合數(shù)據(jù)的容器。其可以是一個單獨的mongod服務，也可以是一個副本集（多個mongod服務，一個是主活躍節(jié)點），這個視使用環(huán)境來確定片的形態(tài)！2 mongos： MongoDB自帶的路由服務進程，它路由所有的客戶端

18、請求，并將各個片的結(jié)果進行匯聚返回。這個服務進程本身不會存儲任何數(shù)據(jù)或配置信息（有時會緩存配置服務器的相關配置信息）。3 配置服務器： 這個也是一個mongod服務進行，但這個數(shù)據(jù)庫服務僅僅是為mongos路由服務提供配置信息存儲的位置！啟動mongos服務時，需要提供一個mongod服務，以便路由服務訪問或存儲相關的配置信息。配置信息主要包括：分片與數(shù)據(jù)的對應關系！，配置服務器不需要很大的空間，估算每200M數(shù)據(jù)需要1KB的配置空分片環(huán)境搭建分片集群設計分片環(huán)境搭建Shard:這里采用副本集實現(xiàn)config=_id:mongoReplset00,members:_id:0,host:192.

19、168.86.128:20002,priority:5,_id:1,host:192.168.86.129:20002,_id:2,host:192.168.86.130:20002,_id:3,host:192.168.86.131:20002,priority:0,hidden:truers.initiate(config);以一個shard為例：分片環(huán)境搭建配置服務器：以一個configServer為例：分片環(huán)境搭建mongs：以一個mongs為例：分片環(huán)境搭建串聯(lián)路由服務器與分配副本集登錄任意一個mongs開啟的mongo服務，在admin庫中執(zhí)行：db.runCommand(adds

20、hard:mongoReplset00/192.168.86.128:20002,192.168.86.129:20002,192.168.86.130:20002);db.runCommand(addshard:mongoReplset01/192.168.86.128:20003,192.168.86.129:20003,192.168.86.131:20003);db.runCommand(addshard:mongoReplset02/192.168.86.128:20004,192.168.86.130:20004,192.168.86.131:20004);db.runComman

21、d(addshard:mongoReplset03/192.168.86.129:20005,192.168.86.130:20005,192.168.86.131:20005);分片環(huán)境搭建指定分片的數(shù)據(jù)庫和分片的集合：同樣登錄mongs的mongo服務，在admin庫中執(zhí)行：#指定wechatdb分片生效db.runCommand(enablesharding:wechatdb);mongosdb.runCommand(enablesharding:wechatdb);ok:1#指定數(shù)據(jù)庫里需要分片的集合和片鍵db.runCommand(shardcollection:wechatdb.person,key:id:1)mongosdb.runCommand(shardcollection:wechatdb.person,key:id:1)collectionsharded:wechatdb.person,ok:1從節(jié)點每個上面的數(shù)據(jù)都是對數(shù)據(jù)庫全量拷貝，