MongoDB分片到复制集改造实践

  • 时间:
  • 浏览:1
  • 来源:uu快3计划_uu快3官方_单双

另外可是我能通过sh.status命令看了被删除shard上的chunk数量不断减少,其余shard的chunk数量增多。

首先,我提供有一种可选方案:

draining数据过程非常缓慢,不能继续通过执行removeShard命令来查看当前具体情况:

最后打开均衡器,这时候许多人庆幸的发现,均衡器又刚开使迁移chunk了。

2)业务从分片访问方式改为复制集访问方式

你不能针对生产级业务环境需求提供最小影响服务将分片改造为复制集(含减分片场景)的出理 方案。

                                           

从上不能看了,anav_team_2上面存在7个jumbo chunk

简单描述业务背景,起初业务评估需求有点硬高,一点许多人采用了分片架构,设计了八个shard,通过_id进行hash分片,但可是我业务远远不难 达到预期目标,再可是我业务什么什么都这麼萎缩,到现在分片集群反而成为了业务负担。为了减少其成本,业务决定将分片替换为复制集,一并将物理机部署改为容器化。一点,许多人提供了如下迁移步骤:

提供有一种方式来定位移动的对象,find后接文档查询query条件,bound则提供要移动块儿的边界,更为精准。

执行完removeShard,许多人再通过sh.status查看的时候不能看了指定shard正在draining数据

mongos以及shard的日志上面可是我能看了相关迁移记录。

可能业务挑选了合理的片键,removeShard会顺利完成,但在许多人业务中仅仅拿_id进行了hash分片,在removeShard过程中许多人遇到了jumbo chunk,是因为无法迁移

进入正题,目前许多人系统有有另一个多shard,第一步要提前确认primary shard,何为primary shard官方说明

本文,我主要讲第二种方案,其核心技术点为removeShard,但经验不知道们,这俩操作往往不必什么什么都这麼顺利完成,许多人可能会遇到primary shard提示,也可能会遇到jumbo chunk无法迁移的间题。下面我拿有有另一个线上正式服务的案例来完正说明。

时候,许多人就不能进行removeShard了,其操作说明官方文档也非常完正。

最后,可能是分片场景,请务必重视: 设计合理片键设计合理的片键设计合理片键念之再三,铭之肺腑。

思路可是我 拆分jumbo chunk为更小的块儿,一点通过均衡器来自动迁移。拿有有另一个jumbo chunk来举例说明:

那为那此要提前确认primary shard,可能可能是primary shard就无法remove,会有如下提示:

当然,可能业务数据量有点硬少,一点可接受一定程度上的业务停服,那可是我能挑选逻辑导出导入的方式。尽管这俩方式最为简便,但因影响服务时间过长,可是我很少会在生产环境中使用。

                                           

3)复制集做一次迁移,迁移到容器上

生产线上使用 MongoDB Sharidng 的场景非常多,但可能业务初期评估只能位可能业务发展不符合预期,为了管理起来更方便,可可以将 Sharding 改造为 复制集。

                                           

                                           

这时候可能该shard为我不能删除的对象,什么什么都这麼不能先删除可能移动那此对象,删除不必解释,正式环境可是我 允许你操作,下面看下movePrimary官方文档

当然迁移过程中可能都会冒出jumbo chunk,解法可是我 重复上面splitChunk操作

简单理解可是我 什么什么都这麼进行分片的集合所在库的shard。那要怎样确认,觉得也简单,笨一点方式可是我 连接每个分片show collection查看即可。可是我能执行sh.status查看

使用moveChunk命令移动块儿到指定的shard:

1)目前有有另一个多shard,remove有有另一个shard

待迁移完shard上所有chunk,执行removeShard会返回成功信息。

遇到jumbo chunk何必 慌张,出理 方式必然是有的。首先,许多人不能想到的方式是不能直接给手动移动?官方也的确提供了moveChunk功能参考文档

许多人取有有另一个min._id和max._id的相当于上面值来进行split。

通过该方式我成功remove了有有另一个shard,只留下primary shard,一点通知业务服务从mongos访问改为复制集方式,上面物理机改容器这俩什么都这麼本文范围内,可是我不再往下去讨论。

MongoDB不允许移动大于chunksize的chunk,可是我许多人不能临时将chunk大小调大,方式为:

jumbo chunk要怎样产生呢?每个分片都会有最大chunk的大小,保存在config.settings上面:

这时候许多人再去查config.chunks,可能看只能该chunk信息。以此类推,一点chunk都split下,sh.status不能看了要删除shard上的chunk数量翻倍

首先保证均衡器是开启的,可能在draining数据的过程中均衡器负责将该shard上面的数据迁移至其余的shard。

移动块儿不可行许多人还有一招不能尝试,那可是我 splitChunk,官方文档

1)可能有同步工具支持,不能挑选从分片全量+增量的方式同步到复制集,一点选个时间点切换;

2)从集群中减分片(removeShard),最后只保留有有另一个shard(复制集),业务接入从mongos改为复制集

我这里是moveChunk失败了,是因为是MongoDB 3.4版本手动moveChunk命令做了个限制。但失败归失败,可能一点版本中使用该功能时,务必注意去掉 _secondaryThrottle,去掉 会强制要求迁移过程间歇进行,每迁移完一点数据,需听候集群中大多数分片成功完成数据复制后再进入下一次迁移。尽管变快迁移的过程,但一并减缓了对系统性能的影响。这在生产环境中还是尤为重要。当然,该选项仅仅适用于复制集shard。

Each database in a sharded cluster has a primary shard that holds all the un-sharded collections for that database. Each database has its own primary shard. The primary shard has no relation to the primary in a replica set.

可能片键设计不合理很容易会是因为一点chunk超出上面大小,另有有另一个均衡器就无法移动这俩块儿。执行sh.status(true)不能看了jumbo chunk,可是我能通过查看config.chunks来获取jumbo chunk的信息: