adminMySQL Service Startup and Recovery Checklist
MySQL service failures can stop WordPress, dashboards, APIs and automation systems. A system admin must know how to inspect service state, startup errors, disk pressure, config mistakes and recovery options without damaging data.
Core principle
MySQL starts only when its config is valid, data directory is readable, disk is writable, memory is available and no critical storage corruption blocks startup.
Checklist
- Check MySQL service status.
- Read recent journal logs.
- Check MySQL error log.
- Check disk space and inode usage.
- Check data directory ownership.
- Check config syntax and recent config changes.
- Check whether another process uses the same port.
- Check memory pressure.
- Restart only after identifying the likely cause.
- Verify application connection after recovery.
Reusable lesson
This applies to WordPress database errors, failed migrations, reboot recovery, full disk incidents, MySQL upgrades and server hardening.
When to Use This Checklist
Use this checklist when MySQL or MariaDB fails to start, crashes after reboot or causes website database connection errors.
Required Tools
SSH access, systemctl, journalctl, MySQL error log, df, ls, ss, application config
Before You Start
Do not delete database files manually to make MySQL start. First read logs and preserve data.
Structured Checklist Steps
- Check service status.
- Read journal logs.
- Read MySQL error log.
- Check disk.
- Check inodes.
- Check data directory ownership.
- Check recent config changes.
- Check port conflict.
- Restart if justified.
- Verify application.
Verification Steps
- MySQL service is active.
- Error cause is identified or ruled out.
- Disk has safe free space.
- Application connects successfully.
- No repeated crash appears in logs.
Rollback Plan
If recovery actions make MySQL worse, stop changes, restore the previous config and use the latest database backup or snapshot before attempting deeper repair.
Common Mistakes
- Restarting repeatedly without logs.
- Deleting files from /var/lib/mysql.
- Ignoring full disk.
- Changing config without backup.
- Not verifying the application after service recovery.
Related Commands
sudo systemctl status mysql
journalctl -u mysql --since "30 minutes ago"
sudo tail -n 100 /var/log/mysql/error.log
df -h
df -i
sudo ss -tulpn | grep 3306
free -h
mysqladmin -u root -p ping