小编Gui*_*eau的帖子

我有一个Amazon (AWS) Aurora数据库集群，并且每天都[Billed] Volume Bytes Used在增加。

我已经使用表检查了所有表的大小（在该集群上的所有数据库中）INFORMATION_SCHEMA.TABLES：

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

总计：53GB

那么为什么我此时被计费近 75GB？

我知道配置的空间永远不会被释放，就像常规 MySQL 服务器上的 ibdata 文件永远不会缩小一样；我没问题。这是记录在案的，并且是可以接受的。

我的问题是，每天向我收费的空间都在增加。而且我确定我暂时没有使用 75GB 的空间。如果我做那样的事情，我会理解的。就好像我通过从表中删除行、删除表甚至删除数据库而释放的存储空间从未被重新使用。

我已经多次联系 AWS（高级）支持，但始终无法得到一个很好的解释为什么会这样。
我收到OPTIMIZE TABLE了在有很多free_space（每个INFORMATION_SCHEMA.TABLES表）的表上运行的建议，或者检查 InnoDB 历史长度，以确保已删除的数据不会仍然保留在回滚段中（参考：MVCC） ，并重新启动实例以确保回滚段已清空。
这些都没有帮助。

我的服务器上有 9 个分区格式化为 XFS。

当我尝试安装其中一个时，它失败了。其他人安装得很好。

root@fileserver2 # mount | grep xfs | head -1
/dev/sdb1 on /mnt/hdd1 type xfs (rw,noatime)

root@fileserver2 # mount -t xfs /dev/sdf3 /mnt/hdd3
mount: wrong fs type, bad option, bad superblock on /dev/sdf3,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

root@fileserver2 # dmesg | tail -2
XFS (sdf3): bad magic number
XFS (sdf3): SB validate failed

所以我尝试使用 xfs_repair -n …

使用干燥驱动器（具有越来越多的坏扇区），在 ext4 日志分区上，cp操作有时会完成而不会出错，但写入的数据要么是错误的，要么就是无法读取（无效参数错误之后阅读其中的一部分），就在文件创建之后。

是否有文件系统可以防止此类事件（可能是 ZFS）？

或者cp在删除源之前，是否有任何命令行应用程序可以代替, 来检查复制的数据是否正常？

我可以只 md5 源文件和新创建的文件，但这对我来说听起来像是一个黑客。

谢谢。

更新：我想我没有足够解释我为什么要问这个问题，因此每个人都假设了一些不是。

我不希望继续使用该驱动器。从我注意到问题的那一刻起，该驱动器就已断开连接。我想要的是防止其他驱动器再次发生这里发生的事情。

我有一个脚本，它使用 cp 定期将一些文件从驱动器 1 复制到驱动器 2，然后很快从驱动器 2 复制到驱动器 3。我面临的问题是 cp 从驱动器 1 复制到驱动器 2 时没有抱怨，即使驱动器 2 上的数据在将其复制到驱动器 3 时无法读取。那时，我从 drive1 上的副本已经被删除了（因为我需要可用空间，而且我的脚本没有报告任何错误，因此我认为 drive2 上的数据是正确的）。所以我丢失了文件。

所以我的问题是：阻止这种情况在未来再次发生的最佳方法是什么？我应该只使用带有校验和的文件系统，还是使用自己进行校验和的复制工具？