有人能告诉我造成这种情况的原因是什么吗？
我有一个 Rook Ceph 集群，其中存储了具有 3x 副本的 MySQL 数据库。我也使用该数据库进行开发，也就是说，删除、更改了大量数据等等。
BinaryLogs 也已启用。
数据库总共占用 27GB，其中 22-24GB 是 BinaryLogs。我可以禁用 BinaryLogs，但 20GB 的作用不大，它们每 3 天清除一次。
如果我从容器/主机（df -h）查看大小，我会看到相同的大小（27GB）。
但是Rook Ceph将此Block Image定义为241GB。
而且我不明白如果块图像应该小 9 倍，为什么这个尺寸会这么大？
有什么想法或提示吗？我可以尝试什么或从哪个方向寻找才能了解原因。
我不熟悉 Ceph，但我认为你测量的内容存在混淆。你从 3 个不同的角度描述了大小，但没有给出获取大小的明确方法（命令行）。
虽然 Ceph 可以存储单个文件，但通过此接口运行 MySQL 数据库会相当奇怪 - 我猜存储是配置为 Ceph 块设备的。在这种情况下，在配置时定义的大小有一个固定的上限，并在您在卷上创建的文件系统中配置。大多数（所有？）存储提供商将实施精简配置- 存储上卷的占用空间只是在卷生命周期中写入的块。Ceph 默认这样做。也就是说，只要您只添加数据，那么占用空间就会反映存储在文件系统中的文件的大小。
但是存储提供商并不了解文件系统 - 它不知道文件何时从文件系统中删除，因此当文件被删除时，底层存储的块仍处于分配状态。使用存储的主机必须告诉 Ceph 块何时不再使用 - 只有在使用 discard 选项挂载文件系统或运行显式 fstrim 命令时，它才会这样做。
另一个考虑因素是，您的存储应设置冗余 - 即当节点发生故障时能够继续提供服务。ceph 集群拥有每个数据块的 3 个（有时甚至更多）副本并不罕见。您的方法可能报告的是物理存储中使用的空间，而不是逻辑占用空间。
非常感谢您的回答。
我想你给了我我所寻找的东西。
是的，我们正在谈论 CephBlockStorage。
我假设 Ceph 会逐步添加但不会删除。我无法用其他方式解释这种大小差异。
我只是不知道如何以及要寻找什么。
关于 3 个副本，我指示的是正确的。因为 3 个副本分别占用 720GB，这在集群中显示出来。
因此，有两个关键字指明了方向：“ discard ”和“ fstrim ”
StorageClass 文档中也描述了有关 discard 的信息 https://kubernetes.io/docs/concepts/storage/storage-classes/#storageclass-objects https://docs.ceph.com/en/latest/rbd/rbd-kubernetes/#create-a-storageclass
但这种解决方案并不是最优的，可能会存在性能问题。
为此，Rook Ceph 建议使用特殊的插件定期执行这项工作。
这是一个相同的问题：https://github.com/rook/rook/issues/10391
以下是解决方案：https：//rook.io/docs/rook/v1.14/Storage-Configuration/Ceph-CSI/ceph-csi-drivers/#csi-addons-operations
我认为问题已经解决了，因为我已经了解了需要配置什么等等。它是否能正常工作是另一个问题。但它应该可以工作。
您的 Rook Ceph 集群中 27GB 的 MySQL 数据库大小与 241GB 的块映像大小之间的差异可能源于 Ceph 管理存储的方式。Ceph 采用精简配置，分配的存储可能看起来比实际存储的数据更大。此外，数据冗余、快照预留和元数据开销等因素也会影响块映像的大小。要进行故障排除，请查看 Ceph 的配置设置，使用 ceph df 等工具监控存储使用情况，并了解精简配置如何影响存储分配。调整设置和监控实践可以帮助优化设置中的存储效率。