I'm running a DigitalOcean.com Virtual Server with the typical Ubuntu LAMP Stack for a few WordPress sites. Of course, every week or two the MySQL service seems to crash. If I restart MySQL or the Server, it's fine. I assume I'm getting hit hard by some hackers that is causing the MySQL connection issue.

Does anyone know a way to automate the restarting of the MySQL service? I was thinking of using a nightly CRON job to restart MySQL, but it seems like there should be a better way. Perhaps I don't have MySQL configured correctly? I'll have to find the MySQL config/ini file.

Edit: I'll dig up the error logs soon. Perhaps it's as simple as a configuration change.

  • 1
    Rather than figuring out how to restart mysql over cron, you should figure out why it is crashing in the first place which is a much more serious problem. What does the mysql logs say? – Chida Aug 2 '14 at 15:22
  • munin. Install munin. – peterh - Reinstate Monica Aug 2 '14 at 15:46
  • @PeterHorvath I guess you mean monit, not munin. But it's still a brute force solution... – zhenech Aug 2 '14 at 16:47

A major problem with all kinds of CMSs are that they are or will be exposed to attacks - especially Wordpress is favorite target. My suggestion will be not to only look at MySQL logs, as you probably only will find the database to be filled up with connections, but look into your web logs aswell. Usually you could try searching for "POST" which in any many cases will show you the attacks/brute force attempts.

So the suggestion will be to locate the problem in the Wordpress installations to lock down any vulnerbilities.

More Wordpress specific things to look at

  1. Brute force attempts on wp-login.php
  2. Comment spam
  3. xmlrpc.php attacks
  • All good points. I am using a plugin that tracks login failures and blocks ip addresses for a certain time period. I'm also writing many of the recorded foreign attacks to a deny list in an .htaccess file. It works well for a while and then they just move to a different IP address. I just wish I could keep the database from failing. – jjwdesign Aug 6 '14 at 13:41
  • 1
    Using such fail2ban like service isn't useful in the long run. It's just a temp fix until the attacks gets destributed - as you mention. You should think different and consider whether you need all services to be public or not. In regards to the 3 mentioned situations, I would usually go for: 1) change url of the login page. 2) disable comments if not needed. 3) deny access (htaccess) to xmlrpc.php if not needed. – SteffenNielsen Aug 7 '14 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.