mongodb分片迁移500GB需要13天-这是缓慢的还是正常的？

我有mongodb分片群集，分片键是哈希值。它具有2个分片副本集。每个副本集有2台计算机。

我通过添加另外2个分片副本集进行了实验，然后开始重新平衡。

但是，一段时间后，我发现块迁移相当缓慢。移动1.4GB数据需要1个小时。

这让我很担心，这意味着我必须等待13天才能完成500GB的块迁移！

我对这些东西还很陌生，我没有上帝会感觉它是缓慢，快速还是正常。但是，这些数字并不能说服我。

关于实验的其他说明：-使用m3中型aws计算机-不运行其他进程，仅迁移块-默认的mongodb分片安装，无需进一步配置-分片使用对象ID（_id）的哈希值-最大块大小为64MB

更新：2018年4月

在提出问题时，这个答案是正确的，但此后情况一直在发展。自从引入3.4版并行性以来，我最初引用的票证已经关闭。有关更多信息，我将在此较新的答案中介绍一些细节。我将其余的答案保持原样，因为它仍然是一般问题/约束的良好参考，并且对较旧版本的任何人均有效。

原始答案

如果您有兴趣的话，我会在M202高级课程中对块迁移的结果进行完整的解释。笼统地说，即使对于空块，迁移也不是非常快，因为要执行管家工作以确保迁移在活动的系统中起作用（即使除了平衡之外什么也不会发生）。

另外，整个集群一次只发生一次迁移-没有并行性。因此，尽管您有两个“完整”节点和两个“空”节点，但在任何给定时间都最多会发生一次迁移（在具有最多块的碎片与具有最少块的碎片之间）。因此，添加2个分片在平衡速度方面不会给您带来任何好处，只会增加必须移动的块数。

对于迁移本身，块的大小可能约为30MiB（取决于填充数据的方式，但是通常这是默认的最大块大小的平均值）。您可以运行其中db.collection.getShardDistribution()的一些信息，并在此处查看我的答案，以获取有关您的块的更多信息的方法。

由于没有其他活动在进行，要进行迁移，目标分片（新添加的分片之一）将需要从源分片（原始的两个分片之一）中读取约30MiB的数据，并将配置服务器更新为完成后反映新的块位置。对于没有负载的普通系统，移动30MiB数据应该不是很大的瓶颈。

如果速度很慢，则有多种可能的原因，但对于不繁忙的系统，最常见的原因是：

• 源磁盘I / O-如果在读取数据时数据不在活动内存中，则必须从磁盘将其分页
• 网络-如果存在延迟，速率限制，数据包丢失等，则读取可能需要一段时间
• 目标磁盘I / O-数据和索引必须写入磁盘，许多索引会使情况变得更糟，但是通常在轻负载的系统上这不是问题
• 迁移导致中止和迁移失败的问题（配置服务器问题，主数据库删除问题）
• 复制滞后-用于迁移到副本集，写关注w:2或w:majority默认情况下使用，并且需要最新的辅助副本来满足。

如果系统很忙，那么内存争用，锁争用通常也会在这里引起怀疑。

要获取有关迁移需要多长时间，迁移失败等的更多信息，请查看您的config.changelog：

// connect to mongos
use config
db.changelog.find()

正如您所看到的，并且正如我通常告诉别人我何时进行培训/教育一样，如果您知道您将需要4个碎片，那么通常最好从4个开始，而不是逐步增加。如果这样做了，那么您需要意识到添加一个分片可能会花费很长时间，并且最初是对资源的净负面影响，而不是收益（请参阅我的分片陷阱系列的第二部分，对此有更详细的讨论）。

最后，要跟踪/支持/评论功能请求以改善块迁移的并行性，请查看SERVER-4355