How to Repair Corrupted MySQL Tables and Handle Crashes in cPanel

Database reliability is essential for dynamic websites, e-commerce stores, and customer management panels. In cPanel environments, MySQL or MariaDB serves as the primary database engine. However, sudden server restarts, disk space exhaustion, or hardware issues can lead to database table corruption or service crashes. When MySQL fails or tables corrupt, visitors are greeted with "Error Establishing a Database Connection" messages, and dynamic functions stop working.

For systems administrators, diagnosing database crashes and repairing corrupted tables is a critical skill. Resolving these issues requires identifying the database storage engine (InnoDB vs. MyISAM), checking system logs, and using the correct repair tools. In this guide, we will explore database corruption causes, check diagnostic logs, and walk through the SSH commands to repair tables and recover from MySQL service crashes.

1. InnoDB vs MyISAM: Storage Engines and Corruption

MySQL uses different storage engines for database tables, with InnoDB and MyISAM being the most common. The recovery and repair process depends on the engine used for the affected table.

MyISAM is a legacy storage engine that stores tables in separate files on disk. MyISAM tables do not support transactions, making them susceptible to corruption during sudden server shutdowns or crashes. However, they are relatively easy to repair. InnoDB is the modern default engine, featuring transactional support and crash-recovery features. While InnoDB tables are more robust, severe corruption can cause the MySQL service to crash repeatedly during startup, requiring specialized recovery steps.

2. Step-by-Step Diagnostic Commands via SSH

To diagnose and repair MySQL issues, log into your server via SSH as the root user. Use these commands to check service logs, run table diagnostics, and configure recovery modes.

Step 2.1: Check MySQL Service Status and Log Files

If your database service is offline, check its status and review the system log files to identify the cause of the failure:

systemctl status mariadb  # On MariaDB servers
systemctl status mysqld   # On MySQL servers

If the service fails to start, review the MySQL error log file to identify the root cause (such as disk space exhaustion, configuration errors, or InnoDB corruption):

tail -n 100 /var/log/mariadb/mariadb.log  # On MariaDB systems
tail -n 100 /var/log/mysqld.log           # On MySQL systems

Step 2.2: Check and Repair MyISAM Tables

If the MySQL service is running but a specific MyISAM table is corrupted, check and repair the table using the mysqlcheck command:

mysqlcheck -c database_name table_name  # Check table integrity
mysqlcheck -r database_name table_name  # Repair table

To check and repair all tables in all databases on the server, run:

mysqlcheck -A --check --auto-repair

If the MySQL service is offline, you can repair MyISAM tables directly on disk using the myisamchk tool in the database directory (usually '/var/lib/mysql/'):

cd /var/lib/mysql/database_name/
myisamchk -r table_name.MYI

Step 2.3: InnoDB Crash Recovery and Force Recovery Mode

InnoDB tables cannot be repaired using standard mysqlcheck -r commands. If an InnoDB table is corrupted, the MySQL service may crash during startup as it tries to run its automated rollback process. When this occurs, you must configure InnoDB Force Recovery.

Open your MySQL configuration file:

nano /etc/my.cnf

Under the [mysqld] section, add the innodb_force_recovery directive, starting at level 1:

[mysqld]
innodb_force_recovery = 1

Save the file and attempt to start the database service. If it fails, increase the recovery level incrementally (from 1 up to a maximum of 4 or 6) until the service starts:

systemctl start mysqld

IMPORTANT: InnoDB force recovery mode should only be used to start the service in read-only mode so you can export your databases. Do not run write operations or leave recovery mode active. Once the service starts, export your databases immediately:

mysqldump database_name > database_backup.sql

After exporting the data, remove the innodb_force_recovery line from /etc/my.cnf, restart MySQL, drop the corrupted database, recreate it, and import your backup:

mysql -e "DROP DATABASE database_name;"
mysql -e "CREATE DATABASE database_name;"
mysql database_name < database_backup.sql

3. MySQL Troubleshooting Checklist

Frequently Asked Questions (FAQ)

Why do MySQL tables corrupt?

Database table corruption is typically caused by sudden server shutdowns (due to power failures or kernel crashes) while write operations are active. It can also occur due to disk space exhaustion, bad memory modules, or hardware write errors on the storage drives.

Is it safe to run InnoDB Force Recovery level 6?

Levels 5 and 6 can lead to data loss as they bypass check constraints and database consistency rules. Only use these levels as a last resort to export your databases when lower recovery levels fail to start the service.

Can cPanel repair databases automatically?

Yes. Users can log into their cPanel dashboard, navigate to **MySQL Databases**, select the target database, and click **Repair Database** to run automated repair diagnostics for MyISAM tables.