Is MySQL Database Corrupt?

Hi, I've had the "Error establishing a database connection" for several days now. I've tried restarting the droplet but to no avail. I've ran a mysql error log and got this back http://postimg.org/image/s6azk2w5d/ (please copy and paste link).

Need more info to diagnose a db page corruption. Try running the following diagnostic commands to see the state of your mysql installation (note: you'll need to enter your mysql root password when prompted, or use a different mysql administrator account/pw).

As you can see on the mysqladmin status output it says it can't connect to the MYSQL through the socket.
I've tried /var/run/mysqld/mysqld.sock to se if it is there but No such file or directory is returned.

@administrator72 - You're defaults also allows for TCP port 3306, so socket /var/run/mysql/mysql.sock is optional. If you want to try using TCP port 3306, you can give mysqladmin the arguments --port=3306 --protocol=TCP along with the other arguments I gave in my previous comment.

I did not see your output to the 'ps' command, so maybe mysql just gave up after detecting the page corruption. You can verify this with service mysql status. If mysql can't start at all after using service mysql start, then your choices are limited. I recommend taking a snapshot of your datadir /var/lib/mysql to somewhere else for a later post-mortem, then try recovering from backup if you have a lot of data you want to recover. Good luck.

Leave a Comment

MySQL can be a tricky service to troubleshoot and can often cause quite a number of headaches. Being we only provide self-managed hosting, we are limited in what we can do for you in such a situation. We may not be able to login and troubleshoot this for you, however we can provide a few different ideas to help guide you in resolving this situation.

The most common cause of MySQL stopping or failing to start is a resullt of memory (ie RAM) issues. This is largely because MySQL is a very resource intensive service. Nearly everything it does uses a good chunk of RAM and IO. The best way to be sure is to try and start MySQL using the command:

After doing such an event, it will normally let you know if it fails. If it does, I recommend reviewing the MySQL log file to see what issue occurred. The log file location is normally at:

For Ubuntu/Debian
/var/log/mysql/error.log
For CentOS/Fedora
/var/log/mariadb/mariadb.log

It should tell you what error occurred if a MySQL error occurred. If you see errors such as "mmap can't allocate," then you know you are hitting memory issues. Potential fixes for that are tuning your MySQL settings (using a binary such a mysqltuner, which is available via the package manager), optimizing any using MySQL (such as a website), and resizing the droplet to a larger size to allow for more memory usage. I strongly recommend doing the first two first, and save doing the resize for when you are sure nothing else can be optimized to use less memory.

Another potential problem could be a lack of disc space or inodes on your droplet. The MySQL log will normally indicate this, but you could confirm it using commands such as:

sudo df -h
sudo df -i

If you see you are very near 100% usage, you will want to either reduce the disc space/inode usage, or resize to a larger package to allow more disc space/inodes. If you are seeing high disc space usage, you can locate large files using a command such as:

sudo find / -type f -size +1G -exec du -h {} \; 2>/dev/null

Another problem could be an application using too much of the MySQL service. You can normally verify this by checking your application's setup, the queries it uses, and any related logs for the application. If you see high traffic that is abnormal (like a ton of xmlrpc.php requests for example), you would want to investigate that to rectify that situation. Often, fixing something like that will resolve the MySQL issue.