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?