Issue Got packet bigger than 'max_allowed_packet' bytes when dumping table

[Pleskian27]

Hi.
There is an article for fixing DB dump:

Unable to export mysql database in Plesk GUI: mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table

Applicable to: Plesk Onyx for Linux Symptoms Unable to export mysql database in Subscriptions > example.com > Databases > Export Dump PLESK_ERROR: Unable to export a dump of database_n...

support.plesk.com

but Plesk backup fails with the same error.
Where is the backup script and how to fix the error?

 

[Bitpalast]

Did you follow the article? What max_allowed_packet_size have you set in the [mysql] and more important in the [mysqldump] sections of your /etc/my.cnf file? Did you restart the database server after the change so that the new configuration values have been applied?

Your screenshot is only a small part of a screenshot that does not give any useful information.

 

[ChristophRo]

We've had a similar (because you did not provide any details, I can only guess though) problem and the complete error message from the "failed" backup was:

WARNING: (Database object 'mydomain_wordpressdb') Unable to make database dump. Error: Failed to exec mysqldump: Exit code: 3: mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' when dumping table `wp_options` at row: 104

Unfortunately, this error message is very missleading, as for one, we have max_allowed_packet configured to 64MB and this database was only like 10MB in size anyway - so there is no way a dump of a single element from this database could ever exceed that limit.

So we checked this database more carefully.
First we performed a repair & optimize over the whole database, but that did not help
The we looked at this mentioned wp_options table more closely and checked this problematic row 104
And what did we see, it was the "cron" row and it contained some garbage value that even let phpmyadmin crash when try to open/edit.
This whole cron option/function is a well known and abused vulnerability in Wordpress....
Some bugs in Wordpress allow(ed) an attacker, to place custom code into that field, that was then executed on a regular interval by Wordpress itself.

So, we assumed that this site got hacked and the attacker placed such a specific code/content into this database field, that even lead to mysqldump errors.

In our case, we then simply emptied the value of this row and were done with

update `wp_options` set `option_value` = '' where `option_name` = 'cron';