分片的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的备份还是相对简单的。

つづく???