Matt N
Basic Pleskian
- Server operating system version
- AlmaLinux 8.10
- Plesk version and microupdate number
- 18.0.74
so recently spun up a new server with AlmaLinux 8.10. It's a fresh install, with nothing except a couple of sudo dnf update commands to make sure it was fully up to date.
Did the install of Plesk, added modules required. Checked for updates, all up to date.
Noted that with Plesk 18.0.74, I could upgrade the MariaDB from 10.11, that was installed "fresh" to 11.4. So I thought that might be a good step before I do a migration of customer sites from an aging machine.
I ticked all the appropriate boxes, and had the plesk Repair Tool opened in a separate tab (as instructed) - just in case.
After the upgrade reported all good, I go the plesk Repair Tool to Check File Permissions - All good. Then asked it to check the db to make sure that its all okay. nd that is where I ran into issues. the Repair Tool reports :
Talk about panic. obviously, this then stops the MariaDB server, and Plesk UI is no longer functioning.
Allowing the Plesk Repair Tool to "repair" it actually breaks it seemingly worse, to the point where you can't even start the MariaDB server.
I ended up having to:
mysqlcheck / mariadbcheck both return all tables with an OK status
however, the /usr/local/psa/admin/bin/repair_innodb --check command still gives the following error:
I've added the following lines to my my.cnf file:
I did have the innodb_data_file_path value at 10M initially.
Do I need to be concerned that the repair tool finds this problem, but when I run the plesk repair all -y command, it gives OK for everything.
Did the install of Plesk, added modules required. Checked for updates, all up to date.
Noted that with Plesk 18.0.74, I could upgrade the MariaDB from 10.11, that was installed "fresh" to 11.4. So I thought that might be a good step before I do a migration of customer sites from an aging machine.
I ticked all the appropriate boxes, and had the plesk Repair Tool opened in a separate tab (as instructed) - just in case.
After the upgrade reported all good, I go the plesk Repair Tool to Check File Permissions - All good. Then asked it to check the db to make sure that its all okay. nd that is where I ran into issues. the Repair Tool reports :
[2025-11-16 14:26:30+11:00] ERROR: InnoDB tablespace file '/var/lib/mysql/ibdata1' is corrupted.
[2025-11-16 14:26:30+11:00] INFO: Repair of InnoDB corruption will require at least 163M of free disk space on / mount point. Currently 1.7T of disk space is available on it
Talk about panic. obviously, this then stops the MariaDB server, and Plesk UI is no longer functioning.
Allowing the Plesk Repair Tool to "repair" it actually breaks it seemingly worse, to the point where you can't even start the MariaDB server.
I ended up having to:
- start the mariadb server in innodb_fast_recovery, and dump the data
- stop the server, and then remove the ibdata1, ib_buffer_pool, ib_logfile0, and the undo00x files
- start the server to allow it to rebuild - often failing, and requiring the removal of the files in step 2 again, as well as all the idb and frm files in each of the databases that where there
mysqlcheck / mariadbcheck both return all tables with an OK status
however, the /usr/local/psa/admin/bin/repair_innodb --check command still gives the following error:
Fail: page::64 invalid Exceeded the maximum allowed checksum mismatch count::1 current::0
{"status": "corrupted", "message": "
[2025-11-16 14:26:30+11:00] ERROR: InnoDB tablespace file '/var/lib/mysql/ibdata1' is corrupted.
[2025-11-16 14:26:30+11:00] INFO: Repair of InnoDB corruption will require at least 163M of free disk space on / mount point. Currently 1.7T of disk space is available on it.
I've added the following lines to my my.cnf file:
innodb_data_file_path = ibdata1:1M:autoextend
#innodb_force_recovery = 1
innodb_file_per_table = ON
I did have the innodb_data_file_path value at 10M initially.
Do I need to be concerned that the repair tool finds this problem, but when I run the plesk repair all -y command, it gives OK for everything.