mongodb 概述

############對mongo db中某個集合做分片################# 本例中test1為資料庫，test1也為集合名===

1、先enable sharding，開啟資料庫的分片功能

mongos> use admin

mongos> db.runCommand({"enablesharding":"test1"})

2、對具體collection做分片, 選擇片鍵為"_id"

mongos> db.runCommand({"shardcollection":"test1.test1","key":{"_id":1}})

{ "collectionsharded" : "test1.test1", "ok" : 1 }

3、觀察2個分片 shard_01  shard_02 tunks 數量

===========MongoDB=====複製集讀寫設定====

write concern 

預設情況下，Primary完成寫操作即返回，Driver可透過設定[Write Concern]來設定寫成功的規則。

如下的write concern規則設定寫必須在大多數節點上成功，超時時間為5s。

cfg = rs.conf()

cfg.settings = {}

cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 }

rs.reconfig(cfg)

資料同步

Primary與Secondary之間透過oplog來同步資料，Primary上的寫操作完成後，會向特殊的local.oplog.rs特殊集合寫入一條oplog，Secondary不斷的從Primary取新的oplog並應用。

因oplog的資料會不斷增加，local.oplog.rs被設定成為一個capped集合，當容量達到配置上限時，會將最舊的資料刪除掉。另外考慮到oplog在Secondary上可能重複應用，oplog必須具有冪等性，即重複應用也會得到相同的結果。

如下oplog的格式，包含ts、h、op、ns、o等欄位

{

  "ts" : Timestamp(1446011584, 2),

  "h" : NumberLong("1687359108795812092"), 

  "v" : 2, 

  "op" : "i", 

  "ns" : "test.nosql", 

  "o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" } 

}

}

ts： 操作時間，當前timestamp + 計數器，計數器每秒都被重置

h：操作的全域性唯一標識

v：oplog版本資訊

op：操作型別

i：插入操作

u：更新操作

d：刪除操作

c：執行命令（如createDatabase，dropDatabase）

n：空操作，特殊用途

ns：操作針對的集合

o：操作內容，如果是更新操作

o2：操作查詢where條件，僅update操作包含該欄位

========oplog 與journal日誌問題==========張友東部落格===========

MongoDB 複製集裡寫入一個文件時，需要修改如下資料

將文件資料寫入對應的集合

更新集合的所有索引資訊

寫入一條oplog用於同步

上面3個修改操作，需要確保要麼都成功，要麼都失敗，不能出現部分成功的情況。

MongoDB 在寫入資料時，會將上述3個操作放到一個 wiredtiger 的事務裡，確保「原子性」

wiredtiger 提交事務時，會將所有修改操作應用，並將上述3個操作寫入到一條 journal 操作日誌裡；後臺會週期性的checkpoint，將修改持久化，並移除無用的journal。

誰先寫入？

oplog 與 journal 是 MongoDB 裡不同層次的概念，放在一起比先後本身是不合理的。

oplog 在 MongoDB 裡是一個普通的集合，所以 oplog 的寫入與普通集合的寫入並無區別。

一次寫入，會對應資料、索引，oplog的修改，而這3個修改，會對應一條journal操作日誌

####====具體部分參考了張友東部落格======#####