分片的一些概念与细节

Primary Shard

在Replica set中有Primary和Secondary的概念，那么在Sharding中其实也有一个Primary的概念。

任何一个mongoDB中都有一个未分区的整体DB的collection在某一个Shard中。如下图。

Collection1在ShardA中有一部分Chunks在ShardB中也有一部分Shards，而在ShardA 中却有一个Collection2保存整体的ShardA+ShardB的Collection1的和。

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