问题
Client just had ~1000 rows of data (most recent, of course), just go missing in one of their tables. Doing some forensics, I found that the "last_updated_date" in all of their other rows of said table was also set to roughly the same time as the deletion occurred. This is not one of their larger tables.
Some other oddities are that the mysqldumps for the last week are all exact same size -- 10375605093 Bytes. Previous dumps grew by about .5GB each. MySQL Dump command is standard:
/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 on the box shows plenty of space (at least 50%) in every directory.
The data loss combined with the fact that their dumps are not increasing in size has me worried that somehow we're hitting some hardcoded limit in MySQL and (God I hope I'm wrong), data is getting corrupted. Anyone ever heard of anything like this? How can we explain the mysqldump sizes?
回答1:
50% free space doesn't mean much if you're doing multiple multi-gig dumps and run out of space halfway. Unless you're storing binary data in your dumps, they are quite compressible, so I'd suggest piping mysqldump's output through gzip before outputting to a file:
mysqldump .... | gzip -9 > /path_to_backup/....
MySQL itself doesn't have any arbitrary limits that say "no more after X gigs", but there are limits imposed by the platform it's running on, detailed here.
回答2:
There is no hardcoded limit to the amount of data MySQL can handle.
来源：https://stackoverflow.com/questions/6962349/mysql-dump-limit-mysql-overall-database-size-limit