【Mongodb】Sharding 手工迁移chunk

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介:
mongodb的数据由monogd服务器存储,由mongos对写入的数据根据片键进行路由,整个过程对客户端完全透明。对chunk的移动是由“平衡器”来决定的,当然加入chunk分布不均匀了,我们也可以手工来操作
db.runCommand( { moveChunk : "" ,
                 find : {查询条件} ,
                 to : "" } )
注释:
moveChunk:一个集合的全字要加上数据库的名称:比如test.yql 
find:一个查询语句,对于指定集合中的符合查询的数据或者chunk,系统自动查出from 的shard
to: 指向chunk的目的shard 
只要目的shard和源sharad同意指定的chunk由目的shard接管,命令就返回。迁移chunk是一个比较复杂的过程,它包括两个内部通信协议:
1 复制数据,包括在复制过程中的变化的数据
2 确保所有参与迁移的组成部分:目的shard ,源shard ,config server都确定迁移已经完成!
比如我们要将 yql.momo中的id>82842的部分由shard0001迁移到shard0002:
mongos> db.printShardingStatus() 
--- Sharding Status --- 
  sharding version: { "_id" : 1, "version" : 3 }
  shards:
        {  "_id" : "shard0000",  "host" : "10.250.7.225:27018" }
        {  "_id" : "shard0001",  "host" : "10.250.7.249:27019" }
        {  "_id" : "shard0002",  "host" : "10.250.7.241:27020" }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "test",  "partitioned" : true,  "primary" : "shard0000" }
                test.momo chunks:
                                shard0001       3
                                shard0002       3
                                shard0000       6
                        { "id" : { $minKey : 1 } } -->> { "id" : 0 } on : shard0001 { "t" : 2000, "i" : 0 }
                        { "id" : 0 } -->> { "id" : 11595 } on : shard0002 { "t" : 3000, "i" : 0 }
                        { "id" : 11595 } -->> { "id" : 23191 } on : shard0001 { "t" : 4000, "i" : 0 }
                        { "id" : 23191 } -->> { "id" : 31929 } on : shard0002 { "t" : 5000, "i" : 0 }
                        { "id" : 31929 } -->> { "id" : 42392 } on : shard0001 { "t" : 6000, "i" : 0 }
                        { "id" : 42392 } -->> { "id" : 62952 } on : shard0002 { "t" : 7000, "i" : 0 }
                        { "id" : 62952 } -->> { "id" : 82842 } on : shard0000 { "t" : 7000, "i" : 1 }
                        { "id" : 82842 } -->> { "id" : 102100 } on : shard0000 { "t" : 1000, "i" : 11 }
                        { "id" : 102100 } -->> { "id" : 120602 } on : shard0000 { "t" : 1000, "i" : 13 }
                        { "id" : 120602 } -->> { "id" : 287873 } on : shard0000 { "t" : 2000, "i" : 2 }
                        { "id" : 287873 } -->> { "id" : 305812 } on : shard0000 { "t" : 2000, "i" : 6 }
                        { "id" : 305812 } -->> { "id" : { $maxKey : 1 } } on : shard0000 { "t" : 2000, "i" : 7 }
                test.yql chunks:
                                shard0001       2
                                shard0000       1
                                shard0002       1
                        { "_id" : { $minKey : 1 } } -->> { "_id" : ObjectId("4eb298b3adbd9673afee95e3") } on : shard0001 { "t" : 4000, "i" : 0 }
                        { "_id" : ObjectId("4eb298b3adbd9673afee95e3") } -->> { "_id" : ObjectId("4eb2a64640643e5bb60072f7") } on : shard0000 { "t" : 4000, "i" : 1 }
                        { "_id" : ObjectId("4eb2a64640643e5bb60072f7") } -->> { "_id" : ObjectId("4eb2a65340643e5bb600e084") } on : shard0002 { "t" : 3000, "i" : 1 }
                        { "_id" : ObjectId("4eb2a65340643e5bb600e084") } -->> { "_id" : { $maxKey : 1 } } on : shard0001 { "t" : 3000, "i" : 0 }
        {  "_id" : "mongos",  "partitioned" : false,  "primary" : "shard0000" }
执行迁移命令:
mongos> db.adminCommand({moveChunk : "test.momo", find : {id:{$gt:82842}}, to : "shard0002"});
{ "millis" : 1474, "ok" : 1 }
再次查看:
mongos> db.printShardingStatus() 
--- Sharding Status --- 
  sharding version: { "_id" : 1, "version" : 3 }
  shards:
        {  "_id" : "shard0000",  "host" : "10.250.7.225:27018" }
        {  "_id" : "shard0001",  "host" : "10.250.7.249:27019" }
        {  "_id" : "shard0002",  "host" : "10.250.7.241:27020" }
  databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
        {  "_id" : "test",  "partitioned" : true,  "primary" : "shard0000" }
                test.momo chunks:
                                shard0001       4
                                shard0000       4
                                shard0002       4
                        { "id" : { $minKey : 1 } } -->> { "id" : 0 } on : shard0001 { "t" : 2000, "i" : 0 }
                        { "id" : 0 } -->> { "id" : 11595 } on : shard0000 { "t" : 11000, "i" : 0 }
                        { "id" : 11595 } -->> { "id" : 23191 } on : shard0001 { "t" : 4000, "i" : 0 }
                        { "id" : 23191 } -->> { "id" : 31929 } on : shard0002 { "t" : 11000, "i" : 1 }
                        { "id" : 31929 } -->> { "id" : 42392 } on : shard0001 { "t" : 6000, "i" : 0 }
                        { "id" : 42392 } -->> { "id" : 62952 } on : shard0002 { "t" : 7000, "i" : 0 }
                        { "id" : 62952 } -->> { "id" : 82842 } on : shard0001 { "t" : 8000, "i" : 0 }
                        { "id" : 82842 } -->> { "id" : 102100 } on : shard0002 { "t" : 9000, "i" : 0 }
                        { "id" : 102100 } -->> { "id" : 120602 } on : shard0000 { "t" : 10000, "i" : 1 }
                        { "id" : 120602 } -->> { "id" : 287873 } on : shard0000 { "t" : 2000, "i" : 2 }
                        { "id" : 287873 } -->> { "id" : 305812 } on : shard0000 { "t" : 2000, "i" : 6 }
                        { "id" : 305812 } -->> { "id" : { $maxKey : 1 } } on : shard0002 { "t" : 10000, "i" : 0 }
                test.yql chunks:
                                shard0001       2
                                shard0000       1
                                shard0002       1
                        { "_id" : { $minKey : 1 } } -->> { "_id" : ObjectId("4eb298b3adbd9673afee95e3") } on : shard0001 { "t" : 4000, "i" : 0 }
                        { "_id" : ObjectId("4eb298b3adbd9673afee95e3") } -->> { "_id" : ObjectId("4eb2a64640643e5bb60072f7") } on : shard0000 { "t" : 4000, "i" : 1 }
                        { "_id" : ObjectId("4eb2a64640643e5bb60072f7") } -->> { "_id" : ObjectId("4eb2a65340643e5bb600e084") } on : shard0002 { "t" : 3000, "i" : 1 }
                        { "_id" : ObjectId("4eb2a65340643e5bb600e084") } -->> { "_id" : { $maxKey : 1 } } on : shard0001 { "t" : 3000, "i" : 0 }
        {  "_id" : "mongos",  "partitioned" : false,  "primary" : "shard0000" }

mongos> 
从结果看出:并非所有id>82842的数据所在的chunk都迁移到了shard0002上面,[82842,102100] 和[305812 ,+∞]迁移到了shard0002.这个有点不明白??
日志记录:
##发命令
Sat Nov  5 16:15:35 [conn1] CMD: movechunk: { moveChunk: "test.momo", find: { id: { $gt: 82842.0 } }, to: "shard0002" }
##迁移数据
Sat Nov  5 16:15:35 [conn1] moving chunk ns: test.momo moving ( ns:test.momo at: shard0000:10.250.7.225:27018 lastmod: 2|7 min: { id: 305812 } max: { id: MaxKey }) shard0000:10.250.7.225:27018 -> shard0002:10.250.7.241:27020
Sat Nov  5 16:15:36 [Balancer] distributed lock 'balancer/rac4:27017:1320477786:1804289383' acquired, ts : 4eb4f0a818ed672581e262dd
Sat Nov  5 16:15:36 [Balancer] distributed lock 'balancer/rac4:27017:1320477786:1804289383' unlocked. 
Sat Nov  5 16:15:37 [conn1] created new distributed lock for test.momo on rac1:28001,rac2:28002,rac3:28003 ( lock timeout : 900000, ping interval : 30000, process : 0 )
Sat Nov  5 16:15:37 [conn1] ChunkManager: time to load chunks for test.momo: 0ms sequenceNumber: 10 version: 10|1
Sat Nov  5 16:15:41 [Balancer] distributed lock 'balancer/rac4:27017:1320477786:1804289383' acquired, ts : 4eb4f0ad18ed672581e262de
Sat Nov  5 16:15:41 [Balancer] chose [shard0002] to [shard0000] { _id: "test.momo-id_0.0", lastmod: Timestamp 3000|0, ns: "test.momo", min: { id: 0.0 }, max: { id: 11595 }, shard: "shard0002" }
Sat Nov  5 16:15:41 [Balancer] moving chunk ns: test.momo moving ( ns:test.momo at: shard0002:10.250.7.241:27020 lastmod: 3|0 min: { id: 0.0 } max: { id: 11595 }) shard0002:10.250.7.241:27020 -> shard0000:10.250.7.225:27018
Sat Nov  5 16:15:43 [Balancer] created new distributed lock for test.momo on rac1:28001,rac2:28002,rac3:28003 ( lock timeout : 900000, ping interval : 30000, process : 0 )
Sat Nov  5 16:15:43 [Balancer] ChunkManager: time to load chunks for test.momo: 0ms sequenceNumber: 11 version: 11|1
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
7月前
|
SQL DataWorks NoSQL
DataWorks报错问题之datax mongodb全量迁移报错如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
|
2月前
|
NoSQL MongoDB 数据库
使用NimoShake将数据从AWS DynamoDB迁移至阿里云MongoDB
使用NimoShake将数据从AWS DynamoDB迁移至阿里云MongoDB
|
4月前
|
JSON NoSQL Ubuntu
在Ubuntu 14.04上如何备份、恢复和迁移MongoDB数据库
在Ubuntu 14.04上如何备份、恢复和迁移MongoDB数据库
95 1
|
4月前
|
NoSQL MongoDB 数据库
DTS 的惊天挑战:迁移海量 MongoDB 数据时,捍卫数据准确完整的生死之战!
【8月更文挑战第7天】在数字化时代,大数据量的MongoDB迁移至关重要。DTS(数据传输服务)通过全面的数据评估、可靠的传输机制(如事务保证一致性)、异常处理(如回滚或重试),以及迁移后的数据校验来确保数据准确无损。DTS还处理数据转换与映射,即使面对不同数据库结构也能保持数据完整性,为企业提供可靠的数据迁移解决方案。
69 2
|
5月前
|
DataWorks NoSQL fastjson
DataWorks操作报错合集之DataX进行MongoDB全量迁移的过程中,DataX的MongoDB Reader插件在初始化阶段找不到Fastjson 2.x版本的类库,该怎么办
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
6月前
|
存储 数据采集 NoSQL
DTS在迁移大数据量的MongoDB数据库时如何保证数据的准确性和完整性?
【6月更文挑战第4天】DTS在迁移大数据量的MongoDB数据库时如何保证数据的准确性和完整性?
147 1
|
存储 NoSQL 分布式数据库
MongoDB性能系列最佳实践-Sharding
MongoDB将会推出一系列介绍MongoDB性能最佳实践的文章,旨在帮助用户在多个关键方面实现规模化性能优化。
MongoDB性能系列最佳实践-Sharding
|
数据采集 NoSQL 容灾
如何实现MongoDB数据的快速迁移?
为解决用户面临的 MongoDB 迁移问题,玖章算术旗下的云原生智能数据管理平台 NineData 推出了 MongoDB 业务不停服数据迁移能力。NineData 实现了完全自动化的全量数据迁移,以及增量数据的采集复制能力。
|
存储 NoSQL Oracle
「数据库选型」卫报从MongoDB迁移到Amazon RDS上的PostgreSQL
「数据库选型」卫报从MongoDB迁移到Amazon RDS上的PostgreSQL
|
存储 JSON NoSQL
「文档数据库迁移」从MongoDB迁移到Apache CouchDB
「文档数据库迁移」从MongoDB迁移到Apache CouchDB