有人能告诉我造成这种情况的原因是什么吗？

我有一个 Rook Ceph 集群，其中存储了具有 3x 副本的 MySQL 数据库。我也使用该数据库进行开发，也就是说，删除、更改了大量数据等等。

BinaryLogs 也已启用。

数据库总共占用 27GB，其中 22-24GB 是 BinaryLogs。我可以禁用 BinaryLogs，但 20GB 的作用不大，它们每 3 天清除一次。

如果我从容器/主机（df -h）查看大小，我会看到相同的大小（27GB）。

但是Rook Ceph将此Block Image定义为241GB。

而且我不明白如果块图像应该小 9 倍，为什么这个尺寸会这么大？

有什么想法或提示吗？我可以尝试什么或从哪个方向寻找才能了解原因。

3

  • Ceph 和 MySQL 在存储方面的主要区别在于它们的设计和数据处理能力。然而，主要区别在于 MySQL 使用模式将数据存储在表中，而 Ceph 主要用于存储非结构化数据，如媒体、备份和其他对象。您还可以借助 Bibin Wilson 和 Shishir Khandelwal 撰写的 Devopscube 文章《方法》来实现这一点，了解更多详细信息。


    – 

  • @Imran Premnawaz – 谢谢你的回答，但我认为你并没有理解问题本身。对于我的问题来说，Docker 镜像大小是另一个领域，与我的问题无关。


    – 

  • 伊姆兰 (Imran) 的评论看起来就像是从聊天机器人直接复制粘贴的。


    – 


最佳答案
3

我不熟悉 Ceph，但我认为你测量的内容存在混淆。你从 3 个不同的角度描述了大小，但没有给出获取大小的明确方法（命令行）。

虽然 Ceph 可以存储单个文件，但通过此接口运行 MySQL 数据库会相当奇怪 – 我猜存储是配置为 Ceph 块设备的。在这种情况下，在配置时定义的大小有一个固定的上限，并在您在卷上创建的文件系统中配置。大多数（所有？）存储提供商将实施精简配置– 存储上卷的占用空间只是在卷生命周期中写入的块。Ceph 默认这样做。也就是说，只要您只添加数据，那么占用空间就会反映存储在文件系统中的文件的大小。

但是存储提供商并不了解文件系统 – 它不知道文件何时从文件系统中删除，因此当文件被删除时，底层存储的块仍处于分配状态。使用存储的主机必须告诉 Ceph 块何时不再使用 – 只有在使用 discard 选项挂载文件系统或运行显式 fstrim 命令时，它才会这样做。

另一个考虑因素是，您的存储应设置冗余 – 即当节点发生故障时能够继续提供服务。ceph 集群拥有每个数据块的 3 个（有时甚至更多）副本并不罕见。您的方法可能报告的是物理存储中使用的空间，而不是逻辑占用空间。

非常感谢您的回答。

我想你给了我我所寻找的东西。

是的，我们正在谈论 CephBlockStorage。

我假设 Ceph 会逐步添加但不会删除。我无法用其他方式解释这种大小差异。

我只是不知道如何以及要寻找什么。

关于 3 个副本，我指示的是正确的。因为 3 个副本分别占用 720GB，这在集群中显示出来。

因此，有两个关键字指明了方向：“ discard ”和“ fstrim ”

StorageClass 文档中也描述了有关 discard 的信息

但这种解决方案并不是最优的，可能会存在性能问题。

为此，Rook Ceph 建议使用特殊的插件定期执行这项工作。

这是一个相同的问题：

以下是解决方案：

我认为问题已经解决了，因为我已经了解了需要配置什么等等。它是否能正常工作是另一个问题。但它应该可以工作。

您的 Rook Ceph 集群中 27GB 的 MySQL 数据库大小与 241GB 的块映像大小之间的差异可能源于 Ceph 管理存储的方式。Ceph 采用精简配置，分配的存储可能看起来比实际存储的数据更大。此外，数据冗余、快照预留和元数据开销等因素也会影响块映像的大小。要进行故障排除，请查看 Ceph 的配置设置，使用 ceph df 等工具监控存储使用情况，并了解精简配置如何影响存储分配。调整设置和监控实践可以帮助优化设置中的存储效率。