I’m sure I can offer some advice on this. I’m sorry about the trouble you’re having here, but you were right to reach out. What you are dealing with is something that so many people deal with who run their own servers. In fact, if you search for the error you will find people everywhere talking about dealing with it for the first time in mass quantities. This to say, MySQL crashes are not at all uncommon. The most common reason for this is the system running out of memory. The quickest short term fix is to log in via SSH or the web console and run “service mysql restart” (“mysqld” for CentOS/Fedora).
There are a few ways to resolve this problem to prevent this from happening again.
1) Resize to a larger droplet (don’t do this until you’ve read the rest). If you are running a full web stack with MySQL, we recommend at least 1GB of memory. However, larger applications may need much more than that, it is very relative to your application.
2) Optimize your MySQL configuration. A great tool for this is MySQLtuner (http://mysqltuner.com). Note that the longer your server has been running before using this, the more accurate its suggestions will be. These settings are adjusted in /etc/my.cnf.
You can get an example of the memory usage from your current or proposed settings with this calculator: http://www.mysqlcalculator.com
3) Reduce your web application’s reliance on MySQL for page loads. This can usually be done by adding static caching to your application. For example, Joomla has caching as a built in feature that can be enabled. Another example, Wordpress can use plugins (like WP Super Cache) to add in this kind of functionality.
Take note that upgrading the droplet is an option, but hardly the one I recommend. Number 3 in my list there is key. The thing about Wordpress is that a 1GB droplet might house one Wordpress site well, and for someone else a 64GB droplet might fail to house their website well. This is why you have to be careful with just upgrading the droplet. I don’t want you to pay more only to find that it doesn’t help you. I only want you to do that if it truly ends up being the only option. The reason droplet size may not have a significant impact is that plugins and themes are capable of driving Wordpress resource needs through the roof. Raising the ceiling seems like the right reaction, but if the problem is bad enough then the problem will simply scale up to the new ceiling and hit the same problem. These are my go to rules for optimizing Wordpress:
- Remove all unnecessary plugins. Disabled is not the same as removed.
- Remove all unused themes.
- Install static caching. Try using WP Super Cache for this.
Keep in mind that some plugins and themes can render static caching ineffective, and in such cases the only thing that you can really do is try to find out which is the cause and consider an alternate solution.
If something like shared hosting better fits your needs, there is no shame in that. You’ve hit what is very typically the first problem that a system administrator faces. Some decide that they want to press forward and learn how to resolve it, no matter how long it takes. Others decide that it isn’t what they wanted to get into, and they outsource it to someone who has more time to take care of it. There is no wrong choice, only the right choice for your needs.