mongodb複製+分片集原理

----------------------------------------複製集----------------------------------------

1、複製集概述：

Mongodb複製集（replica set）由一組Mongod實例（進程）組成，包含一個Primary節點和多個Secondary節點，Mongodb Driver（客戶端）的全部數據都寫入Primary，Secondary經過oplog來同步Primary的數據，保證主從節點數據的一致性；複製集在完成主從複製的基礎上，經過心跳機制，一旦Primary節點出現宕機，則觸發選舉一個新的主節點，剩下的secondary節點指向新的Primary，時間應該在10-30s內完成感知Primary節點故障，實現高可用數據庫集羣

特色：

Primary節點是惟一的，但不是固定的

由大多數據原則保證數據的一致性

Secondary節點沒法寫入（默認狀況下，不使用驅動鏈接時，也是不能查詢的）

相對於傳統的主從結構，複製集能夠自動容災

 

2、複製集原理：

角色（按是否存儲數據劃分）：

Primary：主節點，由選舉產生，負責客戶端的寫操做，產生oplog日誌文件

Secondary：從節點，負責客戶端的讀操做，提供數據的備份和故障的切換

Arbiter：仲裁節點，只參與選舉的投票，不會成爲primary，也不向Primary同步數據，若部署了一個2個節點的複製集，1個Primary，1個Secondary，任意節點宕機，複製集將不能提供服務了（沒法選出Primary），這時能夠給複製集添加一個Arbiter節點，即便有節點宕機，仍能選出Primary

角色（按類型區分）：

Standard（標準）：這種是常規節點，它存儲一份完整的數據副本，參與投票選舉，有可能成爲主節點

Passive（被動）：存儲完整的數據副本，參與投票，不能成爲活躍節點

Arbiter（投票）：仲裁節點只參與投票，不接收復制的數據，也不能成爲活躍節點

注：每一個參與節點（非仲裁者）有個優先權（0-1000），優先權（priority）爲0則是被動的，不能成爲活躍節點，優先權不爲0的，按照由大到小選出活躍節點，優先值同樣的則看誰的數據比較新

注：Mongodb 3.0裏，複製集成員最多50個，參與Primary選舉投票的成員最多7個

 

選舉：

每一個節點經過優先級定義出節點的類型（標準、被動、投票）

標準節點經過對比自身數據進行選舉出primary節點或者secondary節點

影響選舉的因素：

1.心跳檢測：複製集內成員每隔兩秒向其餘成員發送心跳檢測信息，若10秒內無響應，則標記其爲不可用

2.鏈接：在多個節點中，最少保證兩個節點爲活躍狀態，若是集羣中共三個節點，掛掉兩個節點，那麼剩餘的節點不管狀態是primary仍是處於選舉過程當中，都會直接被降權爲secondary

觸發選舉的狀況：

1.初始化狀態

2.從節點們沒法與主節點進行通訊

3.主節點辭職

主節點辭職的狀況：

1.在接收到replSetStepDown命令後

2.在現有的環境中，其餘secondary節點的數據落後於自己10s內，且擁有更高優先級

3.當主節點沒法與羣集中多數節點通訊

注：當主節點辭職後，主節點將關閉自身全部的鏈接，避免出現客戶端在從節點進行寫入操做

 

----------------------------------------分片----------------------------------------

1、分片概述：

分片（sharding）是指將數據庫拆分，將其分散在不一樣的機器上的過程。分片集羣（sharded cluster）是一種水平擴展數據庫系統性能的方法，可以將數據集分佈式存儲在不一樣的分片（shard）上，每一個分片只保存數據集的一部分，MongoDB保證各個分片之間不會有重複的數據，全部分片保存的數據之和就是完整的數據集。分片集羣將數據集分佈式存儲，可以將負載分攤到多個分片上，每一個分片只負責讀寫一部分數據，充分利用了各個shard的系統資源，提升數據庫系統的吞吐量

注：mongodb3.2版本後，分片技術必須結合複製集完成

應用場景：

1.單臺機器的磁盤不夠用了，使用分片解決磁盤空間的問題

2.單個mongod已經不能知足寫數據的性能要求。經過分片讓寫壓力分散到各個分片上面，使用分片服務器自身的資源

3.想把大量數據放到內存裏提升性能。和上面同樣，經過分片使用分片服務器自身的資源

 

2、分片存儲原理：

存儲方式：

數據集被拆分紅數據塊（chunk），每一個數據塊包含多個doc，數據塊分佈式存儲在分片集羣中

角色：

Config server：MongoDB負責追蹤數據塊在shard上的分佈信息，每一個分片存儲哪些數據塊，叫作分片的元數據，保存在config server上的數據庫 config中，通常使用3臺config server，全部config server中的config數據庫必須徹底相同（建議將config server部署在不一樣的服務器，以保證穩定性）

Shard server：將數據進行分片，拆分紅數據塊（chunk），數據塊真正存放的單位

Mongos server：數據庫集羣請求的入口，全部的請求都經過mongos進行協調，查看分片的元數據，查找chunk存放位置，mongos本身就是一個請求分發中心，在生產環境一般有多mongos做爲請求的入口，防止其中一個掛掉全部的mongodb請求都沒有辦法操做

總結：

應用請求mongos來操做mongodb的增刪改查，配置服務器存儲數據庫元信息，而且和mongos作同步，數據最終存入在shard（分片）上，爲了防止數據丟失，同步在副本集中存儲了一份，仲裁節點在數據存儲到分片的時候決定存儲到哪一個節點

 

 

3、分片的片鍵

片鍵是文檔的一個屬性字段或是一個複合索引字段，一旦創建後則不可改變，片鍵是拆分數據的關鍵的依據，如若在數據極爲龐大的場景下，片鍵決定了數據在分片的過程當中數據的存儲位置，直接會影響集羣的性能

注：建立片鍵時，須要有一個支撐片鍵運行的索引

片鍵分類：

1.遞增片鍵：使用時間戳，日期，自增的主鍵，ObjectId，_id等，此類片鍵的寫入操做集中在一個分片服務器上，寫入不具備分散性，這會致使單臺服務器壓力較大，但分割比較容易，這臺服務器可能會成爲性能瓶頸

 

語法解析：
mongos> use 庫名
mongos> db.集合名.ensureIndex({"鍵名":1})                ##建立索引                
mongos> sh.enableSharding("庫名")                        ##開啓庫的分片
mongos> sh.shardCollection("庫名.集合名",{"鍵名":1})        ##開啓集合的分片並指定片鍵

2.哈希片鍵：也稱之爲散列索引，使用一個哈希索引字段做爲片鍵，優勢是使數據在各節點分佈比較均勻，數據寫入可隨機分發到每一個分片服務器上，把寫入的壓力分散到了各個服務器上。可是讀也是隨機的，可能會命中更多的分片，可是缺點是沒法實現範圍區分

 

3.組合片鍵： 數據庫中沒有比較合適的鍵值供片鍵選擇，或者是打算使用的片鍵基數過小（即變化少如星期只有7天可變化），能夠選另外一個字段使用組合片鍵，甚至能夠添加冗餘字段來組合

 

4.標籤片鍵：數據存儲在指定的分片服務器上，能夠爲分片添加tag標籤，而後指定相應的tag，好比讓10.*.*.*(T)出如今shard0000上，11.*.*.*(Q)出如今shard0001或shard0002上，就可使用tag讓均衡器指定分發