管理维护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
共同学习,写下你的评论
评论加载中...
作者其他优质文章