mysql.user表突发损坏，重启后MariaDB无法启动求助

Hey there, sorry to hear your MariaDB/MySQL instance stopped running out of nowhere after a reboot—no upgrades, just a simple restart gone wrong. That’s super frustrating, but let’s walk through some common fixes and checks that usually resolve this kind of issue:

1. First, Grab Basic Status & Error Details #

Start by checking the service’s current status to get immediate clues:

# For systemd-based systems (most modern distros)
systemctl status mariadb -l

# For older SysVinit systems
service mysql status

Also, check the system journal for recent errors related to the service—this often has more context than the status output:

journalctl -u mariadb -xe

Look for keywords like permission denied, disk full, configuration error, or table corruption in the logs.

2. Verify Disk Space Isn’t Full #

A full disk is one of the most common reasons for database services to fail silently. Check your root filesystem and MySQL data directory:

# Check overall disk usage
df -h

# Check MySQL data directory size (default path shown)
du -sh /var/lib/mysql/

If the disk is full, free up space (delete unused files, expand the partition) and try starting the service again.

3. Fix File/Directory Permissions #

MySQL/MariaDB runs under the mysql user by default, and incorrect permissions on the data directory or config files can prevent it from starting. Verify permissions:

# Check data directory ownership
ls -ld /var/lib/mysql/

# Check main config file (path may vary by distro)
ls -l /etc/my.cnf /etc/mysql/my.cnf

If the owner isn’t mysql:mysql, fix it with:

# Stop the service first if it's in a failed state
systemctl stop mariadb

chown -R mysql:mysql /var/lib/mysql/
chmod 750 /var/lib/mysql/

Then try starting the service again.

4. Validate Configuration File Syntax #

A typo or invalid setting in your my.cnf can crash the service on startup. Check for config errors with:

# For MariaDB 10.2+
mysqld --validate-config

# Alternative: Start the daemon in console mode to see real-time errors
mysqld --console

Look for lines like unknown variable or invalid value—fix those in your config file and retry.

5. Check for OOM Killer (Out-of-Memory) #

If your system ran out of memory, the Linux OOM Killer might have terminated the MySQL process. Check for OOM events:

dmesg | grep -i oom
# Or check the kernel journal
journalctl -k | grep -i oom

If you see mentions of mysqld being killed, you’ll need to adjust your MySQL memory settings (lower innodb_buffer_pool_size, key_buffer_size, etc.) or add more RAM/swap to the system.

6. Check for Data Corruption #

If none of the above works, data corruption might be the issue. For InnoDB tables, you can try forced recovery (always back up your data directory first!):

1. Stop the service if running
2. Edit your my.cnf file and add:

   innodb_force_recovery = 1
   

   Start with level 1 (least intrusive) and increment up to 6 if needed.
3. Start the service and immediately export all databases with mysqldump
4. Restore to a fresh data directory or rebuild the instance.

For MyISAM tables, use the myisamchk tool to check and repair tables:

myisamchk --check /var/lib/mysql/*/*.MYI

If you can share specific error messages from the logs we checked earlier, I can help narrow this down further!

内容的提问来源于stack exchange，提问作者3zzy