1. 手动切割chunk主要是两个函数splitAt(fullname,middle)与splitFind(fullname,find). fullname指定哪个库的哪个集合。middle与find都是条件，代表你想手动切割哪个chunk. 需要注意的是条件必须包含片键，不然报错，如下图。 这两个函数不同的是： 1.1 spli
1. 手动切割chunk主要是两个函数splitAt(fullname,middle)与splitFind(fullname,find). fullname指定哪个库的哪个集合。middle与find都是条件，代表你想手动切割哪个chunk. 需要注意的是条件必须包含片键，不然报错，如下图。
这两个函数不同的是：
1.1 splitAt利用middle这个条件找到对应的chunk,并以这个条件所查询到的第一条结果为分隔点，把原先的chunk分隔成两部分。
（一）在手动切隔之前，sar总共有三个块。如下图
（二）执行切割命令
之后chunks的分布如下图
可以看出，执行之后，将第二个chunk，香港虚拟主机，按照{_id:ObjectId("50dc0790525e4314024b79d0")}这个值为分隔点分隔成第2，3两块。
1.2 函数splitFind，官网解释是将找到的第一个chunk分隔成size大小相等的两个chunk.但是我在测试过程中发现并不是这么回事。版本是2.2.2
（一）准备数据。向一个新集合插入250W条有规律的数据。如下图。字段name的值末尾是一个自增的数字。
（二）数据插入之后，集合的分块情况如下图。
（三）我们可以看下，第一块最后一条数据是什么。
（四）可以看到，第一块最后一条数据的name值是"habc780335".也就是说第一块有78W条数据之多。现在将第一块分成两块。使用splitFind()函数。
（五）name值为"habc19"肯定是在第一块中。因为按官网所说，应该将第一块分成size大小相等的两块。可实际上呢？
（六）如上图，的确是将原先的第一块分成了两块。第二块最后一条的ID值就是原先第一块最后一条的ID值。但第1，2这两块size大小是相等的吗？如下图。
（七）如上图。第一块的最后一条数据实际上就是第一条数据。这说明第一块实际上只有一条数据。很显然这两块的size是不相等的。真实情况究竟是什么呢 ？？？
2. 今天在将一个已被移除的shard重新添加进来的时候，出现了问题。特记录下来。
问题：将一个shard移除后，我没有停掉这个shard。后来为了测试我又把它添加进来。db.runCommand({addshard:"hostname:port"}); 操作提示成功。也开始了迁移数据。等迁移完成之后，我进行查询操作，发现操作失败。错误提示是“gotshardname different than what i had before” 。如下图
错误提示是说，这个shard之前添加进来的时候name被赋值为shard0001,现在再次添加进来后name被赋值为shard0000.当进行查询操作时发现这前后name不一样。所以报错。我比较困惑的是，它是怎么知道这个shard之前的name值的。我找遍config库下面的所有collection.都没有发现有地方存储shard之前的name值。仅仅只有shards这个集合存储相关数据。但是存储的都是此时此刻各个shard的情况。问了渡娘与google.没有什么收获。后来没办法，我想把这个shard再一次的remove掉后再添加进来。可以不行。
虽然操作提示是成功的，但是过了很久我发现数据根本就没有迁移。查询日志，发现了错误提示。
错误提示仍是name值前后不一样。后来在同事的提示下，我将这个shard重启，重启后发现问题解决了。
分析：每个添加进去的shard的name值不仅在config库存储，同时各个shard也都存储着这个值。不同的是，config库的数据是落地的，但各个shard是缓存起来的。被移除的shard如果不重启，那么这个name值就一直存在。有一点我不理解的是，既然name值存在，并且再次添加后name不一样却能添加成功，并且数据也都迁移过来了，香港虚拟主机，只是查询操作的时候才报错。难道迁移数据与查询数据使用的是不同地方的name值? 有一点需要注意的是，虽然查询操作失败，但写操作能够成功。
如何避免：db.runCommand({addshard:"hostname:port",name:"xxx"}) VS db,runCommand({addshard:"hostname:port"})。 在addshard的时候，我没有指定name值，系统就使用默认值从shard0000开始递增。因此，在addshard时一定要手动指定name值。
，服务器空间