Database error messages do not always mean table corruption. Error credentials, disk overload, downtime, or connection limitations all produce similar results. Repair is only suitable for verifiable table corruption and does not result in the same result on all engines and types of damage.
Quick answer:First, get a physical or logical backup that can be recovered, check the disk space and MySQL health, find the exact table name and error text from the log, and then run the engine-appropriate repair tool in the storage window. Do not drop or truncate any production tables without backup.
What is the real sign of decay?
- Messages like table marked as crashed
- Index reading error or corruption in log database
- Failure of the CHECK TABLE for the specified table
- Faulty recovery after crash or storage problem
Error establishing a database connection does not prove corruption alone.The error guide for the database connection.Check it out.
Before the repairs.
- Set the site's maintenance window.
- Get backup of the database and files and control the file size.
- Check the disk space, the inode and the health of the storage.
- Identify the engine and the affected table.
- Record the RPO and rollback path.
If the store is active, the old restore can delete the new order and payment.
The internal tools of WordPress
WordPress has a repair page that is activated by the following temporary definition:
define( 'WP_ALLOW_REPAIR', true );The repair page does not require the usual authentication management, so only activate the fixed in the short run and immediately remove it. Do not publicise the URL. This tool does not treat all types of corruption or engines.
WP-CLI
wp db check
wp db repairFirst, run the check. Repair is a transformation operation and must be done with backup, the right root of the site, and the authorized user. Read the MySQL tool output; success of the command does not mean removing the storage cause.
InnoDB and MyISAM are not the same.
REPAIR TABLEIt is mainly used for engines such as MyISAM and is not the general way to fix InnoDB. For InnoDB, the server log, crash recovery, backup and exact version guide of MySQL/MariaDB must be checked. Enabling force recovery and export at server level is advanced and risky and should not be provided as a copying command.
After the repair.
Check the table again, read the MySQL and PHP logs, and check login, write save, cron, and checkout. If corruption occurs, RAM, disk, filesystem, crash shutdown, and database version must be checked.
What if the site still doesn't come up?
Successful repair results only report the health of the structure of the table that can be checked. Connection, privilege, prefix, settings file, or application data may still be defective. Match the database name, user, and host to the current environment, but do not publish the code in the command output or tick. Then read the first new error from the log; the old cached message is not a good basis for subsequent changes.
If the site reads but the writing fails, check the free space, read-only file system, user privilege and replica status. If only one feature, such as search or order, is having trouble, find erroneous tables and queries, and don't manipulate the entire database.
What's the appropriate backup for this incident?
A fresh dump of even a corrupted database can be valuable for recovering healthy records, but it should not replace only a reliable copy. Keep the previous healthy version immutable, check checksum and file readability, and record the timing of each copy. For a scanning site, the difference between the last healthy backup and the moment of the crash should be managed separately.
Just seeing a dump file does not mean that it can be restored. Restore should be tested on a separate environment, with a compatible version of the database. This test should not be performed on a production database or with a vague name to increase the risk of incorrect program connection.
Detecting a malfunctioning infrastructure
Do not assume that repeated corruption is a WordPress problem. I/O messages, host reset, lack of volume space, file system errors, and forced shutdown can be the main causes. Check the status of the service and kernel logs in the same time frame and keep the necessary evidence before speeding up rebooting.
Do not automatically run file level repair or change recovery parameters on a managed service; follow the restrictions and procedures of the provider.
Checklist of return service
- Verify the corrupted tables and browse the new logs.
- Read and write test with non-sensitive data
- Login testing, cron, search and core business operations
- Control of orders generated at the time of the accident.
- Reactivation of traffic and gradual monitoring
- Registration of causes, changes and preventive measures
Dangerous mistakes.
- Unknown SQL execution or corrupted table deletion
- Restore old store database without new data integration
- Keeping WP_ALLOW_REPAIR active
- Attributing every connection error to corruption.
- Optimizing all tables when disk is short
When do you need a specialist?
If InnoDB doesn't come up, there are several tables damaged or storage errors, further changes may reduce the chances of recovery.The technical troubleshooting service of WordPress.It can coordinate database, backup and system layer checks.
Common Questions
Does repair delete the data?
Depending on the type of failure and the engine, there is a possibility of record loss; backup before the action is necessary.
Is optimizing the same as repair?
No. The goal and behavior are different and optimizing the public treatment is not corruption.
Why is this mess happening again?
The disk problem, crash, space shortage or inappropriate shutdown may still remain.