mongodb 叢集維護
1 簡介
   談談mongodb的叢集架構
2 常用的維護命令
   1 檢視狀態 sh.status()
        1 version
        2 shards: 分片叢集shard成員
        3 balancer: 平衡器的相關狀態:執行狀態 嘗試次數
          平衡器 sh.setBalancerState(true) 開啟
          sh.stopBalancer() 關閉
          sh.getBalancerState() 檢視狀態
    4 database: 注意幾個值
        1 partitioned:false代表沒有采用分片
        2 primary s1 代表在s1片上 如果有分片 會列出分片資訊 比如 shard key 和chunks
   2 config服務庫
      db.collection.status()檢視分片資訊
3 如何開啟分片
   1 庫開啟分片功能
      use admin && db.runCommand( { enablesharding : "test" } )
   2 集合片鍵加索引
     use test &&　db.vast.ensureIndex( { id: 1 } )
３建立片鍵
   use admin && db.runCommand( { shardcollection : "test.vast1",key : {id: 1,name:1} } )
 4 資料插入測試
  for(i=0;20000<i<40000;i++){ db.vast1.insert({"id":i,"name":"clsn","age":70,"date":new Date()}); }
  db.vast.stats()
 5 相關總結:
   1 片鍵必須是集合文件中的單索引或者是混合索引
   2 片鍵新增方法sh.shardCollection( namespace, key ) namespace 引數是 database.collection
   3 片鍵一經定義後是無法修改的,定義後有且只有一個,索引本身有唯一性
   4 方法 db啟動分片->分片加索引->collection啟動分片
 4  談分片
  1 理想分片:
  目標:將插入資料均勻分佈到各個分片上；保證CRUD操作能夠利用區域性性；有足夠的粒度進行塊拆分。
  影響:增加可用的RAM，增加可用磁碟空間，減輕單臺伺服器的負載，處理單個mongod無法承受的吞吐量
  分片場景
  1 業務上線時已指定好合理的分片欄位,後期不用再更改
     需要制定合理的分片規則
   2 業務上線制定不合理的分片欄位,後期需要重新制定分片規則
     需要mongodump出資料,再製定分片,mongorestore匯入
   3 業務上線時並沒有指定任何分片欄位,後期需要制定分片規則
    需要指定合理的分片規則,然後執行分片命令,這裡需要的時間比較長,建議後臺執行
   可能出現的問題
    1 資料分配不均勻,常見於片鍵的選擇不合理 可以通過sh.status() shard的數量對比來判斷是否分配不均勻
    2 在move chunk過程中,查詢的資料不準確
 2 分片分類
  範圍分片
   eg:id,date等帶有明顯順序的
   優勢 如果使用升序片鍵，那麼資料物理上會是連續的，有利於基於範圍的查詢
   缺點 1 降低寫入效能,空間塊利用率不高 2 需要大量的move chunk,因為降低了資料均衡處理能力
   啟用命令
   db.runCommand( { shardcollection : "test.vast1",key : {date:1} } )
   Hash 分片
   eg:是使用者名稱 郵件地址 udid(唯一裝置識別符號) md5雜湊值 或者是資料集中其他一些沒有規律的鍵
   優勢 能非常好的平均分配到各個shard上
   缺點 1 查詢效能不高,需要與磁碟更多的IO互動
   啟用命令
   db.runCommand( { shardcollection : "test.vast2",key : {date:"hashed"} } )
   聯合分片
   隨機值+範圍值組成的聯合索引
   推薦
   注意:
   1 採用hash分片的策略chunk總數遠遠小於升序分片的個數
   2 無論採用什麼分片策略都要考慮業務本身,業務快是唯一的條件
5  談談move chunk
   觸發條件
   1 寫入資料時，會先建立一個min,max的chunk，隨著資料量不斷增加，超過分裂閾值，就會觸發chunk分裂
    2 當各個分片的chunk分佈不均衡，會觸發移動過程
   決定機制
   Balancer在工作時，會根據shardtag，集合的chunk數量，shard間的chunk數量差值來決定是否需要遷移
  遷移過程
   1 原分片開始啟動moveChunk命令，在移動的過程中，所有的操作還會指向原來的分片
   2 目標分片開始建立所需要的索引，在3.0以後，moveChunk需要在移動之前，目標分片中存在所有的索引，可以理解為先在目標分片中建立這個索引。
   3 目標分片開始向原分片請求資料，並複製資料
   4 當資料全部寫入到目標分片中，目標分片連線並更新config資料庫對應的塊資訊
   5 最後，原分片將這部分塊刪除。
   6 遷移完成標記sh.status()的balance
    "state" : 0, #0：非活動狀態，1：正在獲取，但還沒有執行，2：正在均衡，遷移，有鎖
    Migration Results for the last 24 hours
    success 數值不斷增長,代表正在進行move chunk
   手動觸發遷移
   希望分隔一個已經存在資料的集合，這個集合所有的資料都在一個分片中
   手動觸發命令
   Sh.moveChunk({“test.vfast1”,{id},”shard_2”})
   引數1為namespace 引數2為片鍵名稱 引數3為shard例項名
  日誌
  moving chunk 可以在route.log中觀測到
  類似於 [Balancer] moving chunk ns
6  叢集自動擴容
 1  無論何種分片方式都可以實現shard的自動擴容
 2 採用db.runCommand({addshard)即可
 3 等待move chunk完成
7  相關錯誤彙總
  1 MongoDB chunk too big to move
    1 sh.stopBalancer() //關閉平衡器
    2 use config && db.chunks.find({jumbo:true}) //查詢大塊
    3 sh.splitAt("db.collection", {shardkye:"拆分的臨界值"})//進行手動拆分
    4 sh.moveChunk("db.collection", {shardkey:"shardkey所在的塊"}, "需要移動的目標分片ID");//進行手動遷移
    5 sh.startBalancer()//開啟平衡器
    總結 2.4.6版本以上，在這個版本里修復了SERVER-9365的問題，能平均地拆分資料塊。值得注意的是，由於有的資料塊包含有非常多的文件，將會花一定的時間將這些大資料塊拆分成可以遷移的小資料塊。在這個過程中，您可能還會看到”chunk too big to move”的錯誤。
8 管理難度
   1單副本集(易)
   2叢集簡單分片(中)
   3叢集複雜分片(難)
補充一點 能簡單就簡單,不要硬上叢集,哪怕上了叢集,要簡單分片,否則管理難度會成倍增大
9 備份補充
 mongo --eval "sh.stopBalancer()" 
 mongodump -o $TAR_FILE_PATH 
 mongo --eval "sh.setBalancerState(true)"