分片的1些概念與細節

Primary Shard

在Replica set中有Primary和Secondary的概念，那末在Sharding中其實也有1個Primary的概念。
任何1個mongoDB中都有1個未分區的整體DB的collection在某1個Shard中。以下圖。

Collection1在ShardA中有1部份Chunks在ShardB中也有1部份Shards，而在ShardA 中卻有1個Collection2保存整體的ShardA+ShardB的Collection1的和。

Config Servers的讀寫操作

什么時候去讀

1個mongos(從app發出的mongo Shard 的routing的service)啟動或重啟的時候。
當1個Chunck移動完了，用最新的metadata更新完config servers的時候。

什么時候去寫

當要去切分Chunks的時候。(切分終了后肯定是要寫入最新的metadata)
當在Shards之間移動Chunks的時候。(移動以后所有的位置變化了，肯定也要寫入最新的metadata)

Config Servers的1些有效性

之前說過Config Servers需要3個。主要是為了高可用性和高冗余性來進行的設計。那末當這3個servers的狀態有變化的時候，整體Shards的處理也會隨之產生變化。
當1⑵個Config Server掛掉的時候，Config Servers的metadata就變成了read-only的狀態，和Replica的Primary掛掉的時候效果類似，Replica的全部集群如果沒有了Primary全部集群就變成了ReadOnly的狀態，而這里的的ReadOnly指的是metadata的狀態。你可以繼續讀寫Shards的數據，但是由于metadata不能改變了，那末依照上面的什么時候去寫中寫的那樣，Chunks的切分和移動就不會產生了。
悲催的情況，當你的3個Config Servers都掛掉的話，其實也沒必要太擔心。只要你1直不重啟mongos你還是可以繼續使用這個Shards的，但是如果你在3個Config Servers掛掉后，在這3個Config Servers恢復之前重啟了mongos那末你的Shards集群也就沒法使用了。從現象上其實可以看出，這些數據應當是持久化在內存中的，1旦重啟內存數據消失那末也就失效了。
所以沒有metadata的集群是沒法運行的。所以metadata的備份和使用就很重要。相對Shards中的大量的實際data來講，metadata還是很輕便和易于使用的，也就是說metadata相對來講是低載入本錢，而且metadata對集群來講也不是必要(比如上面說的掛了1⑶個的時候集群在特定條件下也是可使用的)，所以，Config Server的備份還是相對簡單的。

つづく???