January 12th, 2011, 08:25 AM
Backup fails, but we do not get error messages
MySQL 5.1.49-rel11.3-log (Percona build)
Zmanda Recovery Manager for MySQL 3.1
We recently had to change data centers and the result was an upgraded OS (CentOS), same version of MySQL, new version of Zmanda.
Our old setup using Zmanda worked fine. I know because I did practice full restores.
Our new setup has a strange problem with just one of our schemas. Zmanda says the backup succeeded, but the size of the backup is tiny (only a few Megs). We know that the database is several Gigs in size, so this was what got our attention. When I gunzip the actual backup, the resulting file makes it seem that the process creating it just stopped in the middle of a particular table, but again, no errors are reported.
The table that the backup appears to stop in has "longtext" columns, and the values are very big.
I think that our version of Zmanda has a bug because it is not reporting an error, but mysqldump may have "found" the cause of the error: huge data values in those longtext columns.
Running mysqldump on the command line failed on the same table with the error:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `connector_log_error` at row: nnn
I can fix this for mysqldump (for command line usage), but what about Zmanda? Is there a config file where I can set max_allowed_packet bigger than it is?
January 12th, 2011, 01:06 PM
You can add extra-mysqldump-options parameter to the configuration file for the backup
set. Please open a case if you need more help.
January 13th, 2011, 12:08 PM
test reply after user profile changes - administrator may delete this message if desired