Issue Maria DB 10.11 > 11.4 upgrade results in issues with Plesk Repair Tool - reports innodb corruption in ibdata1

[Matt N]

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 :

[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:

1. start the mariadb server in innodb_fast_recovery, and dump the data
2. stop the server, and then remove the ibdata1, ib_buffer_pool, ib_logfile0, and the undo00x files
3. 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

eventually, I was able to get the server up and running again, and remounted the SQL data.

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.

 

[Sebahat.hadzhi]

Hello, @Matt N . This issue is currently under investigation from our team. As far as I understand it is suspected as a MariaDB upstream issue, but I will be able to provide further clarification later on.

 

[Matt N]

@Sebahat.hadzhi - thanks for following up ... I assume I am safe to trust the mariadbcheck/mysqlcheck that they report it's okay? or should I assume that the ibdata1 is actually corrupt?

Everything other than the Plesk repair tool (both CLI and UI) are the only bits that report an issue. I am concerned about moving my clients sites to this box if there is a potential for a problem.

 

[Matt N]

Everything other than the Plesk repair tool (both CLI and UI) are the only bits that report an issue. I am concerned about moving my clients sites to this box if there is a potential for a problem.

That should have read:

Everything other than the Plesk repair tool (both CLI and UI) report no issue, the Repair Tool is the only thing that reports an issue. I am concerned about moving my clients site to this box if there is a potential for a problem.

 

[Sebahat.hadzhi]

So far, our developers haven't identified any real impact resulting from the thrown error - MariaDB appears to be operating properly. Still, at this point, I cannot guarantee unexpected issues won't arise. I will follow-up with more details as soon as possible. Thank you for your patience in the meantime.