MySQL / MariaDB mysqldump error: Cannot load from mysql.proc. The table is probably corrupted (1728)

Written by Claudio Kuenzler - 3 comments

Published on March 17th 2022 - Listed in MySQL MariaDB Databases Linux Backup

---

During a Debian upgrade (Buster to Bullseye), MariaDB was upgraded.

After MariaDB was upgraded from 10.3 to 10.5, the next day the following errors were shown from the daily mysqldump script:

root@bullseye:~# /root/scripts/backup-mysql.sh
mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'db1'': Cannot load from mysql.proc. The table is probably corrupted (1728)
mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'db2'': Cannot load from mysql.proc. The table is probably corrupted (1728)
mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'mysql'': Cannot load from mysql.proc. The table is probably corrupted (1728)

These errors are showing up due to changes inside the internal mysql database. For example in MariaDB 10.4 the mysql.proc table has changed its storage engine from MyISAM to Aria. This and other potential changes to the mysql database require a "mysql database upgrade".

To fix this, the mysql database needs to be upgraded manually using the mysql_upgrade command:

root@bullseye:~# mysql_upgrade -u root -p
Enter password: **********
Phase 1/7: Checking and upgrading mysql database
Processing databases
mysql
mysql.column_stats                                 OK
mysql.columns_priv                                 OK
mysql.db                                           OK
mysql.event                                        OK
mysql.func                                         OK
mysql.gtid_slave_pos                               OK
mysql.help_category                                OK
mysql.help_keyword                                 OK
mysql.help_relation                                OK
mysql.help_topic                                   OK
mysql.host                                         OK
mysql.index_stats                                  OK
mysql.innodb_index_stats                           OK
mysql.innodb_table_stats                           OK
mysql.plugin                                       OK
mysql.proc                                         OK
mysql.procs_priv                                   OK
mysql.proxies_priv                                 OK
mysql.roles_mapping                                OK
mysql.servers                                      OK
mysql.table_stats                                  OK
mysql.tables_priv                                  OK
mysql.time_zone                                    OK
mysql.time_zone_leap_second                        OK
mysql.time_zone_name                               OK
mysql.time_zone_transition                         OK
mysql.time_zone_transition_type                    OK
mysql.transaction_registry                         OK
mysql.user                                         OK
Phase 2/7: Installing used storage engines... Skipped
Phase 3/7: Fixing views
Phase 4/7: Running 'mysql_fix_privilege_tables'
Phase 5/7: Fixing table and database names
Phase 6/7: Checking and upgrading tables
Processing databases
information_schema
db1
db2
performance_schema
Phase 7/7: Running 'FLUSH PRIVILEGES'
OK

After the upgrade, the mysqldump script works again and the errors are gone:

root@bullseye:~# /root/scripts/backup-mysql.sh && echo $?
0

Add a comment

Show form to leave a comment

Comments (newest first)

Mayes from wrote on Jan 11th, 2025:

Hola! Hemos podido reestablecer los servicios de copias Gracias a esto después de mucho tiempo investigando. Gracias!

---

Matt from wrote on Jul 12th, 2024:

Just wanted to say thanks, your article helped me fix the issue!

---

Ken from wrote on Jun 1st, 2022:

Thanks for the info, it fixes the issue

---