Question

Mysql crashing repeatedly with WordPress on Ubuntu 14.04

Posted October 21, 2014 3.7k views

Created 1gig droplet and gave it 2048m swap.

Most other things are default. Did not change anything with the my.cnf or anything…getting this in my /var/log/mysql/error.log

It seems a little absurd that mysql won’t stay running on a droplet image designed for an app that depends on it no?

141021 00:38:05 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141021 00:38:06 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141021  0:38:06 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
141021  0:38:06 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
141021  0:38:06 [Note] Plugin 'FEDERATED' is disabled.
141021  0:38:06 InnoDB: The InnoDB memory heap is disabled
141021  0:38:06 InnoDB: Mutexes and rw_locks use GCC atomic builtins
141021  0:38:06 InnoDB: Compressed tables use zlib 1.2.8
141021  0:38:06 InnoDB: Using Linux native AIO
141021  0:38:06 InnoDB: Initializing buffer pool, size = 128.0M
141021  0:38:06 InnoDB: Completed initialization of buffer pool
141021  0:38:06 InnoDB: highest supported file format is Barracuda.
141021  0:38:06  InnoDB: Waiting for the background threads to start
141021  0:38:07 InnoDB: 5.5.40 started; log sequence number 4181109
141021  0:38:07 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
141021  0:38:07 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
141021  0:38:07 [Note] Server socket created on IP: '127.0.0.1'.
141021  0:38:07 [Note] Event Scheduler: Loaded 0 events
141021  0:38:07 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
141021  0:39:04 [Note] /usr/sbin/mysqld: Normal shutdown

141021  0:39:04 [Note] Event Scheduler: Purging the queue. 0 events
141021  0:39:04  InnoDB: Starting shutdown...
141021  0:39:06  InnoDB: Shutdown completed; log sequence number 4181119
141021  0:39:06 [Note] /usr/sbin/mysqld: Shutdown complete

141021 00:39:06 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141021 00:39:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
141021  0:39:07 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
141021  0:39:07 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
141021  0:39:07 [Note] Plugin 'FEDERATED' is disabled.
141021  0:39:07 InnoDB: The InnoDB memory heap is disabled
141021  0:39:07 InnoDB: Mutexes and rw_locks use GCC atomic builtins
141021  0:39:07 InnoDB: Compressed tables use zlib 1.2.8
141021  0:39:07 InnoDB: Using Linux native AIO
141021  0:39:07 InnoDB: Initializing buffer pool, size = 128.0M
141021  0:39:07 InnoDB: Completed initialization of buffer pool
141021  0:39:07 InnoDB: highest supported file format is Barracuda.
141021  0:39:07  InnoDB: Waiting for the background threads to start
141021  0:39:08 InnoDB: 5.5.40 started; log sequence number 4181119
141021  0:39:08 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
141021  0:39:08 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
141021  0:39:08 [Note] Server socket created on IP: '127.0.0.1'.
141021  0:39:08 [Note] Event Scheduler: Loaded 0 events
141021  0:39:08 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
1 comment
  • It happens. Sometimes a plugin or theme will have something in it that can crash MySQL.

    I made a script you can run with cron to check if MySQL or Apache have crashed. If so, it will restart the service and send you an email letting you know:

    https://github.com/sierracircle/services-checker

    But that is not the fix, it is just way to track what is happening and keep your website going while you trouble-shoot.

    Next you might consider disabling plugins, and then re-enabling them one by one. If a particular plugin is enabled and suddenly crashes start, you have found your culprit.

    If disabling plugins does not stop the crashes, you can switch (temporarily) to one of the default WordPress themes, and see if crashes stop.

    If that does not work, you might start checking to see if brute-force attacks could be causing the crash. (login-lockdown Wordpress plugin is good for that)

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.

×
3 answers

This question was answered by @sierracircle:

It happens. Sometimes a plugin or theme will have something in it that can crash MySQL.

I made a script you can run with cron to check if MySQL or Apache have crashed. If so, it will restart the service and send you an email letting you know:

https://github.com/sierracircle/services-checker

But that is not the fix, it is just way to track what is happening and keep your website going while you trouble-shoot.

Next you might consider disabling plugins, and then re-enabling them one by one. If a particular plugin is enabled and suddenly crashes start, you have found your culprit.

If disabling plugins does not stop the crashes, you can switch (temporarily) to one of the default WordPress themes, and see if crashes stop.

If that does not work, you might start checking to see if brute-force attacks could be causing the crash. (login-lockdown Wordpress plugin is good for that)

View the original comment

This question was answered by @sierracircle:

It happens. Sometimes a plugin or theme will have something in it that can crash MySQL.

I made a script you can run with cron to check if MySQL or Apache have crashed. If so, it will restart the service and send you an email letting you know:

https://github.com/sierracircle/services-checker

But that is not the fix, it is just way to track what is happening and keep your website going while you trouble-shoot.

Next you might consider disabling plugins, and then re-enabling them one by one. If a particular plugin is enabled and suddenly crashes start, you have found your culprit.

If disabling plugins does not stop the crashes, you can switch (temporarily) to one of the default WordPress themes, and see if crashes stop.

If that does not work, you might start checking to see if brute-force attacks could be causing the crash. (login-lockdown Wordpress plugin is good for that)

View the original comment

Hello,

You can check if the MySQL innodbbufferpool_size is not set to a value that exceeds the available RAM on your droplet.

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 http://mysqltuner.pl/ -O mysqltuner.pl
  • Then execute it:
perl mysqltuner.pl

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:

https://www.digitalocean.com/products/managed-databases-mysql/

This was mini tutorial was posted from @bobbyiliev in this question in our community: https://www.digitalocean.com/community/questions/how-to-tweak-mysql-mariadb-configuration-for-increased-performance-and-stability

You can also create a simple bash script to check if MySQL is running and if not to restart it.

#!/bin/bash

# Check if MySQL is running
sudo service mysql status > /dev/null 2>&1

# Restart the MySQL service if it's not running.
if [ $? != 0 ]; then
    sudo service mysql restart
fi

Run this script every 5 minutes using a cron job like this one:

 */5 * * * * /home/user/scripts/monitor.sh > /dev/null 2>&1

Hope that this helps!
Regards,
Alex

Submit an Answer