1

客户只有大约 1000 行数据（当然是最近的），只是在他们的一张表中丢失了。做一些取证，我发现他们所有其他行中的“last_updated_date”也被设置为与删除发生的时间大致相同。这不是他们较大的桌子之一。

其他一些奇怪的是，上周的 mysqldump大小完全相同—— 10375605093 字节。以前的转储每个都增加了大约 0.5GB。MySQL Dump 命令是标准的：

/path/to/mysqldump -S /path/to/mysqld2.sock --lock-all-tables -u username -ppassword database > /path-to-backup/$(date +%Y%m%d)_live_data.mysqldump

盒子上的 df -h 显示每个目录中有足够的空间（至少 50%）。

数据丢失加上他们的转储大小没有增加的事实让我担心我们会以某种方式在 MySQL 中达到一些硬编码限制并且（上帝希望我错了），数据正在损坏。有人听说过这样的事吗？我们如何解释 mysqldump 的大小？

4

2 回答 2

3

如果您正在执行多个多 gig 转储并且中途空间不足，那么 50% 的可用空间并不意味着什么。除非您在转储中存储二进制数据，否则它们是非常可压缩的，所以我建议在输出到文件之前通过 gzip 管道 mysqldump 的输出：

mysqldump .... | gzip -9 > /path_to_backup/....

MySQL 本身并没有任何“在 X gigs 之后不再存在”的任意限制，但它所运行的平台存在限制，详情请参见此处。

于 2011-08-05T20:45:13.867 回答
0

MySQL 可以处理的数据量没有硬编码限制。

于 2011-08-05T20:44:44.977 回答