mongodb shareded cluster中的概念

mongodb的分片集群包含下面的几部分：
shared：每个shared包含一系列的分片数据，每个shared可以部署为单个的replica set
mongos：这个是个查询路由，在客户端和集群间提供接口
config servers:配置server，存放了元数据和集群的配置信息，3.2版本中，配置server可以部署为一个replica set
拓扑图的连接：
https://docs.mongodb.com/manual/sharding/

mongodb分片数据是在集合级别分片的，将集合的数据均衡分布在集群中。
为了在集合中分片，mongodb使用分片键，是在目标集合中的document中存在的字段组成。
分片的集合只能有1个分片键。对于非空的集合，集合必须有一个已分片键开始的索引，对于空的集合，mongodb会创建一个索引。
mongodb将分片的数据放入chunks中，每个chunk包含一个以分片键划分排他的最小值，最大值范围。mongo使用shared cluster balancer来将chunks在集群中进行平衡的迁移。

对于不包含分片键或包含分片键的组合查询，mongos不是路由，而是进行广播操作，会查询集群中的所有的分片。
一个数据库可以混合分片和非分片集合，分片的集合把分区分散在集群中的分片上，对于非分片的集合会存放在主分片上，每一个数据库都有他自己的主分片。

连接到一个分片集群上的方式就是连接mongos
mongodb有2个分片的策略
hash分片
这个对于键值不经常改变，没有很多范围查询的情况下比较有用。
范围分片
就是按照分片键来进行范围分片，需要注意的就是分区键的选择，需要让数据尽可能的均衡。

分片集群的一些限制：
一些操作不能使用
https://docs.mongodb.com/manual/core/sharded-cluster-requirements/#sharding-operational-restrictions

线上部署的考虑：
将配置server配置成1个包含3个成员的replica set
对每个shard配置成包含3个成员的replica set
部署一个或多个mongos路由器。
分片至少需要2个shard来分散分片数据，选择primary shard是通过选择一个数据量最小的shard。

查看shard状态：
sh.status()
配置server不能共享，只能单独使用，每个分片集群有自己的配置server.

配置server如果使用replica set的模式，那么必须要使用WiredTiger 存储引擎。
有下面的一些限制：
不能有arbiters,不能有部署的成员。
必须构建索引。
mongos中会缓存配置信息，所以如果配置server不可用了，只要没有重启mongos，那么是可以继续使用的。配置server包含了元数据，元数据反应了在分片集群中的各个组件的状态和组织情况，包含了在每个分片上的chunk列表，及chunk的范围。只会在下面的几种情况下写数据到配置server,
1chunk迁移2chunk分裂

如果配置server replica set丢失了主，不能选举主，那么集群的元数据是只读的，你可以继续在分片中读取和写入数据，但是不能进行chunk迁移和分裂。配置server都坏了，那集群可能会不可用了。
配置信息存储在了配置数据库，要访问配置数据库，使用
use config
正常情况下，是不应该编辑config数据库的。
对于转发server
The mongos then merges the data from each of the targeted shards and returns the result document. Certain query modifiers, such as sorting, are performed on a shard such as the primary shard before mongos retrieves the results.
对于一些查询描述符的处理：
https://docs.mongodb.com/manual/core/sharded-cluster-query-router/
要分片一个集合，需要使用下面的方法：
sh.shardCollection( namespace, key )

默认的chunk大小是64m，可以修改chunk的大小，小的chunk的就是能让数据更均衡分布，但是在mongos层转发会耗费时间。大的chunk导致更少的迁移，在内部负载和路由层的负载较低，但是数据可能会不均衡。

自动分裂只是在插入或更新的时候发生，但是你减少了chunk的大小，可能会让所有的chunk分裂。分裂的操作不是可回撤的，如果增大了chunk的大小，那么已存在的chunk的大小直到增加到新的大小才会分裂。
分裂chunk是为了防止chunk太大，当达到了指定的chunk大小，或是chunk上的文档数量超过了 Maximum Number of Documents Per Chunk to Migrate,mongodb会基于分片键来分裂，分裂可能导致集合的chunk分布不平衡，在这种情况下，mongos会初始化一个迁移来让chunk重新分布在分片上。
chunk的迁移：
手工迁移
自动迁移：当集合的chunk分布不均衡的时候，balancer进程自动迁移

如果最大分片和最小分片的差距超过了migration thresholds的时候，balancer开始迁移。
在一些情况下，chunk是不能分裂的，可以超过指定的大小，通常是一个chunk代表了一个单分片键的值。
在mongodb2.6开始，sharding.archiveMovedChunks默认情况下是被启用的，原始的数据被保存在了storage.dbPath下的moveChunk目录下。
如果在迁移的过程中发生了错误，这些文件可以用来恢复，在迁移完成后，如果没有文件损坏，可以删除这些文件，可见这部分随着时间慢慢会越来越大，需要注意，可以通过查看sh.isBalancerRunning()来看所有的迁移任务十分已经完成。使用sh.status()来查看集群中的chunk分布。手工分片的命令：https://docs.mongodb.com/manual/tutorial/split-chunks-in-sharded-cluster/

修改chunk的大小：
1通过mongo连接mongos
2切换到config库
use config
3db.settings.save( { _id:”chunksize”, value: } )

对于balancer，可以禁用或者是设置窗口，来减小对线上环境的影响。
chunk迁移的过程：
https://docs.mongodb.com/manual/core/sharding-balancer-administration/
查看balancer状态：sh.status()
查看balancer是否激活：
use config
db.locks.find( { _id : “balancer” } ).pretty()

查看集群中的所有数据库：
use config
db.databases.find( { “partitioned”: true } )或db.databases.find()

列出当前分片信息：
use admin
db.runCommand( { listShards : 1 } )

sh.status()