备案控制台
文档
产品文档
输入文档关键字查找
首页 云数据库 MongoDB 版 实践教程 如何确认增加或删除Shard节点的进度

如何确认增加或删除Shard节点的进度

更新时间：
一键部署
产品详情
相关技术圈
我的收藏

本文介绍如何查看增加Shard节点或删除Shard节点的任务进度，以及检查是否有异常阻塞任务进程的方法。

背景信息

当您对分片集群实例执行增加Shard节点或删除Shard节点操作后，可能会出现任务提交后很长时间都没完成的情况，以下内容将指导您如何检查上述问题。

在进行操作前，您需要了解以下基本知识：

  • 了解MongoDB副本集实例和分片集群实例的部署模式以及两种架构之间的区别。更多介绍，请参见副本集架构和分片集群架构。

  • 了解均衡器Balancer的基本工作原理。更多介绍，请参见管理MongoDB均衡器Balancer。

  • 了解MongoDB数据的划分方式，MongoDB的数据是根据Chunk（块）进行划分的。

  • 了解MongoDB分片集群实例常见的运维命令，例如sh.status()等。

  • 了解mongo shell、mongosh或其他可视化工具的基础使用方式。

检查任务进程

步骤一：检查Balancer是否开启

在增加或删除分片任务中，Chunk的迁移是依赖Balancer完成的。如果未开启Balancer则会导致如下情况：

  • 新增Shard节点：Chunk数据无法迁移到新的Shard节点上，同时也无法承载业务流量。

  • 删除Shard节点：待删除Shard节点上的Chunk数据无法迁移，导致删除Shard节点的任务被阻塞。

因此，您需要开启Balancer来保障Chunk数据的正常迁移。开启Balancer的方法，请参见管理MongoDB均衡器Balancer。

确认Balancer是否开启有如下两种方法：

  • 方法一：sh.status()命令

    Balancer已开启的状态下，返回示例如下。

    ...
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  yes
                Balancer active window is set between 08:30 and 11:30 server local time
...

    如果显示“Currently enabled: no”，则表示Balancer未开启。

  • 方法二：sh.getBalancerState()命令

    • 如果返回true，则表示已开启Balancer。

    • 如果返回false，则表示未开启Balancer。

步骤二：检查Balancer窗口期是否过小

Balancer控制了Chunk数据迁移的速度，Balancer仅会在窗口期时间段内迁移Chunk数据，若当前窗口期未迁移完成，会在下个窗口期继续迁移，直至迁移完成。当窗口期过小时，可能会拖慢增加Shard节点或删除Shard节点任务流的整体进度。调整Balancer窗口期的方法，请参见管理MongoDB均衡器Balancer。

您可以通过如下两种方法检查Balancer的窗口期：

  • 方法一：sh.status()命令

    返回示例如下，可以了解到Balancer的窗口期为当地时间的08:30至11:30，共计3个小时。

    ...
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  yes
                Balancer active window is set between 08:30 and 11:30 server local time
...

  • 方法二：sh.getBalancerWindow()命令

    返回示例如下，当实例中的分片集合较多时，采用此方法能够更直观的显示窗口期时间。

    { "start" : "08:30", "stop" : "11:30" }

步骤三：获取预估任务进度的必要信息

评估任务进度前，您需要获取Balancer的运行结果（成功和失败数量的统计）以及待迁移分片表的Chunk信息。

您可以通过如下两种方法获取Balancer的运行结果和待迁移分片表Chunk信息：

  • 方法一：通过sh.status()命令的输出结果获取

    sh.status()命令的输出结果仅需要关注两部分信息，第一部分为最近时间Balancer运行的结果，示例如下。

    ...
  balancer:
        Collections with active migrations: 
                <db>.<collection> started at Wed Sep 27 2023 10:25:21 GMT+0800 (CST)
        Failed balancer rounds in last 5 attempts:  0
        Migration Results for the last 24 hours: 
                300 : Success
  databases:
...

    第二部分为待迁移的分片表的Chunk信息，示例如下。

    ...
databases:
...
    {  "_id" : "<db>",  "primary" : "d-xxxxxxxxxxxxxxx3",  "partitioned" : true,  "version" : {  "uuid" : UUID("3409a337-c370-4425-ad72-8b8c6b0abd52"),  "lastMod" : 1 } }
          <db>.<collection>
                        shard key: { "<shard_key>" : "hashed" }
                        unique: false
                        balancing: true
                        chunks:
                                d-xxxxxxxxxxxxxxx1      13630
                                d-xxxxxxxxxxxxxxx2      13629
                                d-xxxxxxxxxxxxxxx3      13652
                                d-xxxxxxxxxxxxxxx4      13630
                                d-xxxxxxxxxxxxxxx5      3719
                        too many chunks to print, use verbose if you want to force print
...

    以上示例中的“d-xxxxxxxxxxxxxxx5”即为新增的Shard节点。您也可以在分区表所在的库执行getShardDistribution命令来获取Chunk数据的分布信息，示例如下。

    use <db>
db.<collection>.getShardDistribution()

  • 方法二：直接读取config库中的相关信息

    查看Chunks统计，按分片聚合，示例如下。

    db.getSiblingDB("config").chunks.aggregate([{$group: {_id: "$shard", count: {$sum: 1}}}])

    查看指定分片上的Chunks，按namespace聚合，示例如下。

    db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx"}},{$group: {_id: "$ns", count: {$sum: 1}}}])

    查看过去1天内成功迁移到指定Shard节点的Chunk数量，示例如下。

    // details.to指定chunk迁移的目标shard
// time字段用ISODate指定时间范围
db.getSiblingDB("config").changelog.find({"what" : "moveChunk.commit", "details.to" : "d-xxxxxxxxxxxxx","time" : {"$gte": ISODate("2023-09-26T00:00:00")}}).count()

步骤四：预估任务进度及完成时间

获取分片表已成功迁移的Chunk数量以及当前分片表数据分布情况后，您就可以预估出任务的整体进度和预期完成时间。

假如当前增加Shard节点的场景中，总Chunk数量保持不变，Shard节点数量也保持不变（期间不会有新增或删除Shard节点的任务），增加Shard节点的过程中业务负载基本保持固定，且Balancer的参数设置均为默认值。以上述步骤的示例为例，可以得知以下信息：

  • Shard节点数量为5。

  • 在Balancer窗口期内，成功迁移的Chunk数量为300个。

  • 分片表<db>.<collection>的总Chunk数量为58260个（13630+13629+13652+13630+3719=58260）。

因此可以计算出：

  • 达到均衡状态时，每个分片上的Chunk数量应为11652个（58260÷5=11652）。

  • 按照当前的迁移速度，任务完成还需要26.4天（（11652-3719）÷300≈26.4）。

  • 该增加Shard节点任务进度为32%（3719÷11652=32%）。

说明

实际的业务场景中，总Chunk数量还会随着业务写入以及Chunk分裂而增加。因此假设条件为理想情况，实际耗时可能会更久。

步骤五：确认任务流是否阻塞（删除Shard节点）

如果删除Shard节点的任务被阻塞，执行sh.status()命令后，返回信息中没有看到过去时间段有Chunk数据迁移成功，且待删除Shard节点上依然残留部分Chunk数据未迁移走。此时删除Shard节点任务无法完成，并且会影响您在云数据库MongoDB控制台对实例的其他运维操作。

上述场景中sh.status()命令的返回信息示例如下图所示。

image.png

出现上述问题可能是因为Jumbo Chunk阻塞了删除Shard节点的进程，您可以通过如下的命令确认。

db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx", jumbo:true}},{$group: {_id: "$ns", count: {$sum: 1}}}])

一般情况下，出现Jumbo Chunk是因为设计的分片键（Shard Key）不合理（例如存在热点Key）等因素导致。您可以在业务侧进行如下方法尝试解决：

  • 如果您的MongoDB数据库的大版本为4.4，则可以通过refineCollectionShardKey命令来优化您的Shard key设计，通过为原本分片键添加后缀的方式来使得分片键的基数更大，从而解决Jumbo Chunk的问题。

  • 如果您的MongoDB数据库的大版本为5.0及以上，则可以通过reshardCollection命令来将指定分片表按照新的分片键重新分片。更多介绍，请参见Reshard a Collection。

  • 如果您确认部分业务数据可删除的话，则可以删除对应Jumbo Chunk中的数据，该方法可以减少Jumbo Chunk的大小。减少数据后Jumbo Chunk可能成为一个普通的Chunk，然后被均衡器Balancer迁出。

  • 您可以调大chunkSize参数来使判断Jumbo Chunk的条件发生变化，建议在阿里云技术支持工程师的协助下进行操作。

如果以上方法都无法解决您的问题，建议您提交工单联系技术支持协助解决。

加速新增或删除任务进程

如果您希望增加Shard节点或删除Shard节点的整体流程可以在更短的时间内完成，您可以尝试以下加速方法：

  • 将Balancer的窗口期时间调大，Chunk迁移过程带来的额外负载可能会对业务侧产生影响，请您评估风险后再进行调整。调整Balancer窗口期的方法，请参见管理MongoDB均衡器Balancer。

  • 在业务低峰期手动执行moveChunk操作，更多介绍，请参见sh.moveChunk()。示例如下。

    sh.moveChunk("<db>.<collection>", {"<shard_key>": <value>}, "d-xxxxxxxxxxxxx")
// example：
sh.moveChunk("records.people", { zipcode: "53187" }, "shard0019")

  • 提交工单联系技术支持对相关内核参数进行调整。

相关文档

文档推荐
  • 本页导读 （1）
文档反馈