MongoDB副本集：数据库大小差异

Question

在MongoDB副本集的主节点和从节点中，数据库大小存在差异的可能原因有哪些？在我的设置中，从节点数据库比主节点更大。两个节点具有相同数量的对象，但“avgObjSize”、“dataSize”、“storageSize”的值对于从节点来说更高。同时，通过rs.stats()检查，没有复制滞后。

我可以检查什么？

- Ankit

---

你正在使用不同版本的MongoDB吗？ - yaoxing

MongoDB副本集中主节点和从节点磁盘大小差异问题的解决方法。 - Lalit Agarwal

我必须坦言，以下的回答只有在辅助节点小于主节点时才有意义，但实际情况并非如此，因此它们没有意义。你能给我们展示一些真实的统计数据，比如db.collection.stats()和rs.stats()吗？ - Sammaye

我最近将我们的MongoDB转换为副本集，并对Secondary报告的较小大小感到担忧（117GB v. 106 GB）。然而，数据完全正常和完整。正如其他人所提到的，罪魁祸首很大程度上可以归因于填充因子和索引的差异。需要考虑的进一步事项是每个实例的基础配置 - 它们是否在不同类型的驱动器、FS格式化、块大小上。在我的情况下，我们有一个主要的Raid阵列和一个次要的同样大小的单独驱动器在另一台机器上。 - Brandon K

Answer 1

简介： 由于二级节点未回收的内存空间不同，在二级和一级上设置的补齐系数也不同，可能会出现这种情况。

详细信息： 如果您有一个长时间运行的主节点，在该节点上删除和插入了某些文档，并且没有运行紧缩操作，则此空间将不会被回收，并且将计入数据大小、平均对象大小和存储大小中。从主节点可以完全重新同步到辅助节点，但只能重放当前操作日志中的操作。在这种情况下，二级节点的 dataSize、avgObjSize 和 storageSize 可能会更低。如果之后将二级节点选举为主节点，则可能会看到所描述的差异。另外，每个服务器都有自己的补齐因子，这就是为什么您会看到数据大小不同的原因。

具体场景可能会有所不同，但两个主要原因是：未回收的内存空间量和不同的补齐系数。

- Andrei Beziazychnyi

---

@Sammaye 一般来说，我同意你的观点，但是secondary和primary并不是永久的状态。Secondary可以被选为primary，那么secondary将会有更大的数字。 - Andrei Beziazychnyi

你的解释很有道理。是的，集合的填充因子在辅助节点中比主节点高。我会检查/确认这个节点之前是否作为主节点。 - Ankit

确实，但断言主键已更改只是瞎猜。 - Sammaye

啊，等一下，我看到你在回答中提到了那个，好的。 - Sammaye

有没有官方文档可以让我了解更多关于这个的信息？ - rrrocky

我在这里没有找到任何与此相关的信息：https://docs.mongodb.com/manual/core/replica-set-sync/#initial-sync - rrrocky

Answer 2

可能是由于填充因子的概念。MongoDB为未来的更新留出一些空间，这样当对象的大小增长时，您不必总是将对象移动到另一个存储空间。
可以在您的集合统计信息中找到填充因子：

db.colname.stats()

一个示例结果：

{
"ns" : "merchant.product",
"count" : 24,
"size" : 23168,
"avgObjSize" : 965.3333333333334,
"storageSize" : 204800,
"numExtents" : 2,
"nindexes" : 1,
"lastExtentSize" : 163840,
"paddingFactor" : 1.0000000000000053,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : 8176,
"indexSizes" : {
    "_id_" : 8176
},
"ok" : 1
}

当您更新集合时，MongoDB会更改值填充因子。因此，您的两个节点之间可能存在轻微差异，因为它们可能不是同时创建的。

当您的“填充”不满足对象的新大小时，MongoDB会将其移动到另一个存储空间。然后，原始空间留给未来使用，对象占用新的空间块。但是，由于填充因子的不同，这种行为在您的两个节点中可能也有所不同。

因此，大小通常是可以接受的。

- yaoxing