管理维护Sharding

列出所有的Shard Server

214657857.png

查看Sharding信息

214942604.png

215023732.png

判断是否是Sharding

215123257.png

对现有的表进行Sharding

刚才我们是对表test.users 进行分片了，下面我们将对库中现有的未分片的表test.users_2 进

行分片处理

表最初状态如下，可以看出他没有被分片过：

215455266.png

对其进行分片处理:

215838532.png

再次查看分片后的表的状态，可以看到它已经被我们分片了

215927827.png

220022158.png

新增Shard Server

刚才我们演示的是新增分片表，接下来我们演示如何新增Shard Server

启动一个新Shard Server 进程

220323242.png

配置新Shard Server

220603709.png

220701107.png

查看分片表状态，以验证新Shard Server

221114855.png

221200143.png

221323242.png

我们可以发现，当我们新增Shard Server 后数据自动分布到了新Shard 上，这是由MongoDB

内部自已实现的。

移除Shard Server

有些时候有于硬件资源有限，所以我们不得不进行一些回收工作，下面我们就要将刚刚启用

的Shard Server 回收，系统首先会将在这个即将被移除的Shard Server 上的数据先平均分配

到其它的Shard Server 上，然后最终在将这个Shard Server 踢下线, 我们需要不停的调用

db.runCommand({"removeshard" : "localhost:20002"});来观察这个移除操作进行到哪里了：

221947126.png

222202949.png

最终移除后，当我们再次调用db.runCommand({"removeshard" : "localhost:20002"});的时候系统

会报错，已便通知我们不存在20002 这个端口的Shard Server 了，因为它已经被移除掉了。

接下来我们看一下表中的数据分布：

223003561.png

223220174.png

223309224.png

可以看出数据又被平均分配到了另外2 台Shard Server 上了，对业务没什么特别大的影响。

但是为什么节点还存在呢，这里留了一个疑问？？？

©著作权归作者所有：来自51CTO博客作者shayang88的原创作品，如需转载，请注明出处，否则将追究法律责任

分片MongoDBShardingMongoDB