免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1824 | 回复: 0

[MongoDB] MongoDB sharding迁移那些事(一) [复制链接]

求职 : Linux运维
论坛徽章:
203
拜羊年徽章
日期:2015-03-03 16:15:432015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:57:092015小元宵徽章
日期:2015-03-06 15:58:182015年亚洲杯之约旦
日期:2015-04-05 20:08:292015年亚洲杯之澳大利亚
日期:2015-04-09 09:25:552015年亚洲杯之约旦
日期:2015-04-10 17:34:102015年亚洲杯之巴勒斯坦
日期:2015-04-10 17:35:342015年亚洲杯之日本
日期:2015-04-16 16:28:552015年亚洲杯纪念徽章
日期:2015-04-27 23:29:17操作系统版块每日发帖之星
日期:2015-06-06 22:20:00操作系统版块每日发帖之星
日期:2015-06-09 22:20:00
发表于 2016-09-28 22:04 |显示全部楼层



MongoDB Sharded cluster架构原理
关于MongoDB Sharding,你应该知道的
关于 sharding 迁移,会分3个部分来介绍,本文为第一部分

负载均衡及迁移策略
chunk 迁移流程
Balancer 运维管理
为什么要进行 chunk 迁移?

MongoDB sharding 主要有3个场景需要进行 chunk 迁移

场景1

当多个 shard 上 chunk 数量分布不均时,MongoDB 会自动的在 shard 间迁移 chunk,尽可能让各个 shard 上 chunk 数量均匀分布,就是大家经常说到的负载均衡。

场景2

用户调用 removeShard 命令后,被移除 shard 上的 chunk 就需要被迁移到其他的 shard 上,等该 shard 上没有数据后,安全下线。(注意: shard 上没有分片的集合,需要手动的 movePrimary 来迁移,系统不会自动的迁移)。

场景3

MongoDB sharding 支持 shard tag功能,可以对 shard、及shard key range 打标签,系统会自动将对应 range 的数据迁移到拥有相同 tag 的 shard 上。例如

mongos> sh.addShardTag("shard-hz", "hangzhou")
mongos> sh.addShardTag("shard-sh", "shanghai")
mongos> sh.addTagRange("shtest.coll", {x: 1}, {x: 1000}, "hangzhou")
mongos> sh.addTagRange("shtest.coll", {x: 2000}, {x: 5000}, "shanghai")
对2个 shard 添加了标签,对某个集合的shard key range 也添加了标签,这样该集合里 x 值为[1, 1000)的文档都会分布到 shard-hz,而 x 值为[2000, 5000)的文档则会分布到 shard-sh 里。

迁移工作谁来做?

3.2版本里,Mongos 有个后台的 Balancer 任务,该任务不断对针对上述3种场景来判断是否需要迁移 chunk,如果需要,则发送 moveChunk 命令到源 shard 上开始迁移,整个迁移过程比较复杂,将在第二部分进行专门的介绍。

除了上述场景会触发自动 chunk 迁移,MongoDB 也提供了 moveChunk 命令,让用户能主动的触发数据迁移。

Balancer 如何工作?

一个 Sharded Cluster 里可能有很多个 mongos,如果所有的 mongos 的 Balancer 同时去触发迁移,整个集群就乱了,为了不出乱子,同一时刻只能让一个 Balancer 去做负载均衡。

Balancer 在开始负载均衡前,会先抢锁,抢到锁的 Balancer 继续干活,没抢到锁的则继续等待,一段时间后再尝试抢锁。

这里的锁实际上是config server里 config.locks集合下的一个特殊文档,Balancer 使用 findAndModify 命令去更新文档的 state 字段(类似set state=1 if state==0的逻辑),更新成功即为抢锁成功。

抢锁成功后,Balancer 就开始遍历所有分片的集合,针对每个集合,执行下述步骤,看是否需要 进行 chunk 迁移。

Step1: 获取集合对应的 chunk 分布信息

获取 shard 的元信息 (draining代表 shard 是否正在被移除)

SHARD 名        MAXSIZE        DRAINING        TAG        HOST
shard0        100G        false        tag0        replset0
shard1        100G        false        tag1        replset1
获取集合的 chunk 分布信息

SHARD 名        CHUNK 列表
shard0        chunk(min, -100), chunk(-100, 0)
shard1        chunk(0, 100), chunk(100, max)
获取集合对应的 tag 信息

RANGE        TAG
(20, 80)        tag0
Step2: 检查是否需要 chunk 分裂

如果集合没有设置 tag range,这个步骤不需要做任何事情。其主要是检查 TagRange 跟 chunk 是否存在存在交叉,如果有,则以 Range.min(Range 的下限)为分割点,对 chunk 进行 split。例如

上述(20, 80)的 Range的 tag 为『tag0』,跟chunk(0, 100)有交叉的部分,于是就会在20这个点进行分裂,分裂为 chunk(0, 20) 以及 chunk(20, 100),接下来就可以将 chunk(20, 100)从 shard1 迁移到 shard0,就能满足 tag 分布规则了,这个步骤只是为迁移做准备工作,具体的迁移在 Step4 中完成。

Step3: 迁移 draining shard 上的chunk

当用户 removeShard 将某个 shard 移除时,MongoDB 会将该 shard 标记为 draining 状态, Blancer 在做迁移时,如果发现某个 shard 处于 draining 状态,就会主动将shard 上的chunk 迁移到其他 shard。 Blancer 会挑选拥有最少 chunk 的 shard 作为迁移目标,构建迁移任务。

Step4: 迁移 tag 不匹配的 chunk

Step2 时,已经将 chunk 根据 tag range 边界进行了 split,这时 Balancer 只需要检查哪些 chunk 所属 shard 的 tag 与自身的不匹配,如果不匹配,则构建迁移任务,将 chunk 迁移到 tag 匹配的 shard 上。

Step5: 负载均衡迁移

Balancer 还会基于各个 shard 持有的 chunk 数量来做负载均衡迁移,如果一个集合在2个 shard 里的 chunk 数量相差超过一定阈值,则会触发迁移。 (通过对比持有 chunk 最多和最少的 shard)

集合的 CHUNK 数量        迁移阈值
小于20        2
小于80        4
大于或等于80        8
迁移阈值如上表所示,意思是当集合的 chunk 数量小于20时,如果2个 shard 间 chunk 数量相差大于或等于2时,就会构建迁移任务,将某个 chunk 从『持有 chunk 最多的 shard』迁移到『持有 chunk 最少的 shard』。

Step5:执行迁移

根据 Step 3~5 里构建出的迁移任务,开始真正的迁移。

值得注意的是,Step3、Step4里的迁移虽然是必须要做的,为了确保系统功能正常运转,但其仍然是由 Balancer 来控制的,如果关闭了 Balancer,就可能导致 removeShard、shard tag 逻辑无法正常工作,所以关闭 Balancer 一定要慎重,Balancer 的运维管理将在第三部分详细介绍。


您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP