MongoDB Replication
Primary 接受所有從client傳來的寫入操作
Replica set (副本集) 只會有一個 Primary，因為只有一個成員接受寫入操作。副本集提供嚴格的一致性，對所有從 Primary 的讀取。
為了支持複製操作，Primary 記錄其所有對其數據集的操作到他的 oplog (operations log)。
Secondaries 複製 Primary 的 oplog 到自己的數據集。
Secondaries 的數據集印射 Primary 的數據集。
如果 Primary 不能用，Replica set 會選出一個 Secondary 成為 Primary。
預設情況下，clients 從 Primary 讀取，但是 clients 可以指定一個喜好的來發送讀取操作到 Secondary。從 Secondaries 讀取返回的資料可能不會反射 Primary 的狀態。
你可以增加一個額外的 mongod 實例作為 replica set的 Arbiter (仲裁者)。它不用來維護數據集，只存在於選舉投票。
一個 Secondary 可能會經由一次選舉變為 Primary。
ps:
預設當作primary的server未經initiate()不會被設定為primary，無法在上面進行任何DB操作
作為secondary的server在arbiter未被建立前不會跟primary同步資料
MongoDB Sharding
Sharding 是將儲存資料跨不同機器的方法。
高查詢率會消耗 Server CPU 的能力，大型資料超過單一機器儲存的上限。
為了解決這些問題資料庫有兩種解決方式：
- Vertical scaling : 垂直擴展，就是增加 CPU、增加 Ram 跟增加更多的儲存資源。
- Horizontal scaling : 水平擴展，使用 sharding(分片)機制，分割數據集使之可以跨越在多個 Server 中，或shards(碎片)。
每個 shard 都是一個獨立的資料庫，很多個 shards 可以組成單一個邏輯資料庫。
Sharding 減少了每個 Server 需要儲存的資料量。當 Cluster(集群)增長時，每個 Shard 儲存了更少的資料量。
舉例來說，一個資料庫擁有 1TB 的資料數據，分成4個 shards 來存，每個需管理 256GB 的資料量。
假如分配給40個 shards，每個 shard 只需管理 25GB 的資料而已。
一個 MongoDB 的 Sharded Cluster 由以下元件組成 : shards， query routers 及 config servers。
Shards : 用來儲存資料，為了提高可用性和資料的一致性，在 production 的
Sharded Cluster 每個 Shard 通常是一個 Replica Set (副本集)。Query Routers : 在 MongoDB 裡稱為 mongos，作為讓 client 端可以直接操作到對應的 shards的一個介面。一個 Sharded Cluster 可以擁有多個 Routers 來分擔 client 發過來的要求。
Config servers : 儲存 cluster 的 metadata(用來描述資料屬性)
Data Partitions(資料分割)
Sharding partitions a collection’s data by the shard key.
Shard Keys
要對一個collection做分片(shard)，需要選擇 shard key。
MongoDB 由 shard key 將資料分割成許多的 chunks 平均分佈在 shards。依據 range based 和 hash based 不同種的 shard key，可以對資料做不同的儲存策略。
Range Based Sharding
Hash Based Sharding
Customized Data Distribution with Tag Aware Sharding
維持分散資料平衡
MongoDB使用兩個背景程式處理確保一個 blanced cluster：splitting & balancer.
Splitting
Splitting，一個背景程式，確保 chunks 的成長不會太大。當一個 chunk 成長為指定的 chunk 大小(specified chunk size)時，會將 chunk 分成兩半。
MongoDB 預設的 chunk size 為 64 MB，你可以增加或減少 chunks size。
- 比較小的 chunks，會讓資料更均勻的分佈，但是在資料搬移時花費更多的成本。
- 比較大的 chunks，無論是從網路的角度和在內部開銷方面，讓資料做比較少的搬移。但是這些效率可能會造成資料分佈不均的代價。
- chunk 的大小，會影響每個 chunk 搬移(migrate)的最大文件數量。
Blancing
Blancer，一個背景程式，來管理 chunks 資料的搬移。Blancer 可以藉由 cluster 任何的 query routers 來被執行。
實作練習
使用 MongoDB 這樣做的優點，對延展(scaling)方便資料，並擁有一定的可靠度。當資料儲存空間快不足時，可以對其增加新的 shards，增加 cluster server 的儲存量。
已有三台可用的 server 機，利用這三台機器組成一個 Sharded Cluster Server。
目前規劃架構，每台機器各擁有一個 query router server (mongos) ，各一個 config server，這三台機器組成的 cluster server 擁有 3 個 cluster shards，每個 shard 都是一個副本集 (replica set)，分散在3台機器裡。