分片的一些概念与细节
Primary Shard
在Replica set中有Primary和Secondary的概念，那么在Sharding中其实也有一个Primary的概念。
任何一个mongoDB中如果有未进行sharding的collection，那么这些collections就会被存储在一个shard节点中，这个shard节点就叫做Primary Shard。
The term “primary” shard has nothing to do with the term primary in the context of replica sets
mongoDB中特别强调，这个Primary和Replica的Primary没有任何关系。
Config Servers的读写操作
何时去读
一个mongos(从app发出的mongo Shard 的routing的service)启动或者重启的时候。
当一个Chunck移动完了，用最新的metadata更新完config servers的时候。
何时去写
当要去切分Chunks的时候。(切分完毕后肯定是要写入最新的metadata)
当在Shards之间移动Chunks的时候。(移动以后所有的位置变化了，肯定也要写入最新的metadata)
Config Servers的一些有效性
之前说过Config Servers需要3个。主要是为了高可用性和高冗余性来进行的设计。那么当这3个servers的状态有变化的时候，整体Shards的处理也会随之发生变化。
当1-2个Config Server挂掉的时候，Config Servers的metadata就变成了read-only的状态，和Replica的Primary挂掉的时候效果类似，Replica的整个集群如果没有了Primary整个集群就变成了ReadOnly的状态，而这里的的ReadOnly指的是metadata的状态。你可以继续读写Shards的数据，但是因为metadata不能改变了，那么依照上面的何时去写中写的那样，Chunks的切分以及移动就不会发生了。
悲催的情况，当你的3个Config Servers都挂掉的话，其实也不必太担心。只要你一直不重启mongos你还是可以继续使用这个Shards的，但是如果你在3个Config Servers挂掉后，在这三个Config Servers恢复之前重启了mongos那么你的Shards集群也就无法使用了。从现象上其实可以看出，这些数据应该是持久化在内存中的，一旦重启内存数据消失那么也就失效了。
所以没有metadata的集群是无法运行的。所以metadata的备份以及使用就很重要。相对于Shards中的大量的实际data来说，metadata还是很轻便和易于使用的，也就是说metadata相对来说是低载入成本，而且metadata对于集群来说也不是必要(比如上面说的挂了1-3个的时候集群在特定条件下也是可以使用的)，所以，Config Server的备份还是相对简单的。
つづく・・・
