MongoDB's reading Notes (05) _ "Sharding" (02) _ Some concepts and small details of the Shard

some concepts and details of sharding Primary Shard

There is a concept of primary and secondary in the replica set, so there is a primary concept in sharding.
Any one mongodb has an unpartitioned whole DB collection in one shard. Such as.

Collection1 in the Sharda part of the chunks in the SHARDB also has a part shards, but in Sharda there is a Collection2 to save the whole sharda+shardb of Collection1 and.

Config Servers Read and write operation when to read

A MONGOs (from the app Mongo Shard's routing service) starts or restarts.
When a CHUNCK has finished moving, update config servers with the latest metadata.

when to write

When it's time to slice the chunks. (It must be written to the latest metadata after slicing)
When moving chunks between shards. (All position changes after the move, must also write to the latest metadata)

some validity of Config servers

Previously said config servers requires 3. Designed primarily for high availability and high redundancy. So when the state of these 3 servers changes, the processing of the whole shards will change as well.
When the 1-2 config server hangs, config servers's metadata becomes the read-only state, and the primary of replica is similar when it is hung off. Replica the entire cluster without primary the entire cluster becomes readonly state, and here the ReadOnly refers to the state of metadata. You can continue to read and write shards data, but because metadata can not change, then according to the above time to write in the writing, the chunks of the segmentation and movement will not happen.
The sad situation, when your 3 config servers all hangs, actually also need not worry too much. As long as you do not restart the MONGOs you can still continue to use this shards, but if you have 3 config servers, after the three config servers restored before the MONGOs then your shards cluster will not be able to use. From the phenomenon, it can be seen that the data should be persisted in memory, once the restart of memory data disappear then it will be invalidated.
So a cluster without metadata is not able to run. So the backup and use of metadata is very important. Compared to the large number of actual data in shards, metadata is still very light and easy to use, that is to say metadata is relatively low load cost, and metadata is not necessary for the cluster ( For example, the above says that the cluster is also available under certain conditions when it hangs 1-3, so a backup of Config server is relatively simple.

つづく???

MongoDB's reading Notes (05) _ "Sharding" (02) _ Some concepts and small details of the Shard