How to know the reason MySQL keep crashing?

Posted September 10, 2014 57k views

Hi, currently I have a simple droplet (5 USD) with debian, a basic webserver with a wordpress with 100 visits per day, for some reason Mysql crash randomly, at the beginning I started the service manually, this was very annoying because my site was offline for several days until I realized wordpress was down, right now I have monit who monitors mysql and restart the service if it crash, I solved partially the problem but I still dont know why mysql keep crashing.

Note: there is no mysql.log in /var/log/mysql/


These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
8 answers

I had the same issue, with a 2GB droplet size. Tried everything and eventually discovered it was an XML-RPC attack (Wordpress related).

Check this article for help:
How To Protect WordPress from XML-RPC Attacks on Ubuntu 14.04

by Jon Schwenn
WordPress is a popular and powerful CMS (content management system) platform. Its popularity can bring unwanted attention in the form of malicious traffic specially targeted at a WordPress site. There are many instances where a server that has not been protected or optimized could experience issues or errors after receiving a small amount of malicious traffic. This guide will show you how to protect WordPress from XML-RPC attacks on an Ubuntu 14.04 system.

This is definitely caused by the oom kernel killer beacause of mysql using up all your RAM (and swap if any). I solved this by looking at my mysql error log at /var/log/mysql/error.log and reverting changes made to my systems/sites by the time of error.

Turns out a wordpress plugin caused my problem and once it was out. I was back up with lots of free memory. (I deleted the plugin manually since there was no way to access the site without crashing mysql - see Managing Plugins - WordPress)

You could use the free -m command when logged in via ssh to check which specific site is causing mysql to use up so much memory and debug appropriately. Hope this helps

Most likely this due to running out of memory. Take a look through /var/log/syslog for any messages from the kernel’s Out Of Memory (OOM) killer.

MySql logs are sometimes also found in /var/log/mysql.log and /var/log/mysql.err instead of the /var/log/mysql/ directory. They might provide some hints.

If you haven’t done so already, you should add a swap file to give yourself some leeway when your memory consumption grows.

by Justin Ellingwood
Swap space can be used as an "overflow" area for your system when you run out of RAM. The operating system can store data that would normally be kept in RAM on the hard drive in a specially formatted file. In this guide, we'll demonstrate how to create and use one of these files in Ubuntu 14.04.

Perhaps try specifying a log file in /etc/mysql/my.cnf as follows:

general_log_file      = /var/log/mysql/mysql.log
general_log             = 1

I’m also guessing memory issues.

Currently having this problem as well. Just added swap, but now my 512MB droplet has become seriously slow and my site wont even open.

Will try the other stuff adityars suggested.


We are having the same issue here. I find lots of forum posts about the same issue, but no ‘official’ recommendation… just 'try this’, 'could be that’, 'perhaps its..’.

PLEASE is there any procedure to follow in order to know 1) what´s causing the issue and 2) take proper action?

thks for your time.

I had mysql crashing every 30 minutes exactly. Turns out mysql installs on Windows still default the flushtime to 1800 seconds (on nix boxes this value defaults to 0). Normally this is not a problem, but because I was using federated tables it was a problem. I guess mysql doesn’t know how to flush federated tables, therefore crash. So I set flushtime = 0 in my.ini and the problem went away.

This bug has been reported here:


What you can also do is to use the MySQLTuner script.

The MySQLTuner is a script written in Perl and allows you to quickly test your MySQL configuration and it gives you suggestions for adjustments to increase performance and stability.

According to the official GitHub page, it supports 300 indicators for MySQL/MariaDB/Percona Server in this last version.

To run the script you could do the following:

  • SSH to your Droplet
  • Download the script:
wget -O
  • Then execute it:

The script would run multiple checks against your MySQL instance, all checks done by MySQLTuner are documented here.

Also as stated in the official documentation, it is still extremely important for you to fully understand each change you make to a MySQL database server. If you don’t understand portions of the script’s output, or if you don’t understand the recommendations, you should consult a knowledgeable DBA or system administrator that you trust.

As a good practice make sure to always test your changes on staging environments before implementing them on your production database.

On the same note, if you want to have a worry-free MySQL hosting and focus on your application, I would recommend trying out the DigitalOcean Managed Databases:

This was mini tutorial was posted from @bobbyiliev in this question in our community:

Hope that this helps!