MySQL keeps crashing
I found this occurred when MySQL used up too much RAM. This question and this post both helped with a way to test and a solution.
For me, adding this to my /etc/mysql/my.cnf file fixed the issue.
innodb_buffer_pool_size = 12M
Here's how I decided how much memory to allocate. Start everything but MySQL and check how much memory is free. Set your InnoDB buffer to 10% of that amount. For me it was 12M.
There's a couple of things that will help your installation run without any crashes. I've had similar issues in the past with WordPress, and it's likely that you're either not utilising your InnoDB correctly. From the looks of the log above, as well as details from the post you've added a significant Swap, which has likely either done nothing, or made the problem worse...
First thing's first, your 4GB swap memory is far too high for such a small server. The majority of your processes are likely being used through swap memory. Reduce the swap memory to 512mb or 1gb and troubleshoot from there. Second thing to do is check out the swapiness configuration. If it's too high then your system will aggressively use swap memory - which wastes cycles, and slows data recovery, if it's too low then you might as well not have it at all. The default is 60, I recommend starting at 10 and working your way up from there until you find a "sweet spot" for your server. See this Ubuntu article for how to change it on your system: https://help.ubuntu.com/community/SwapFaq#What_is_swappiness_and_how_do_I_change_it.3F
Your InnoDB buffer is pretty small at 128.0MB. The 4GB swap memory is likely never touched by MySQL (so your swap is probably being used by Apache/PHP if at all). That's probably why it's crashing. Increase your InnoDB by at least double, in reality I'd suggest trying to have the full DB in that buffer, but I understand it's not really possible due to RAM constraints. Try to aim for 1/2 your RAM size, see how it runs compared to before and lower or increase it depending on your results. MySQL Workbench has a 'Server Status' tool that telly you your InnoDB Buffer Usage, ideally you want it to run at just under 100% (80-90% in an ideal world) with enough redundant space in case you get any spikes.
A quick note: If you put your entire DB into RAM you'll need to do more robust & frequent db backups (it's volatile, and if everything's in there and the system looses power that's you screwed).
If these still don't make any big impacts, then look into more robust cacheing for your WP site. Loading every page on every request is going to be pretty taxing, and could be resolved without too much effort. Check out the Server Stats page on MySQL and look up how many Queries Per Second your site is running, compared to InnoDB reads/writes per second.
I had a similar problem and was able to finally fix it.
Background
I tried a bunch of tutorials that recommended tuning my MySQL installation and Apache configuration with no luck.
Identifying the Problem
It turns out that my site was being subjected to a brute force attack that targeted the WordPress xmlrpc.php file.
In order to check for this, you should view your apache2 access logs and look for suspicious POST requests. In my case, I found a huge number of POST requests to the /xmlrpc.php file coming from the same IP address (about 2 or 3 requests per second).
cd /var/log/apache2/
cat access.log
Solution
In order to fix this, I banned the offending IP address via Iptables:
Ban IP the malicious IP address (replace example with whatever IP address you want to ban) :
iptables -A INPUT -s 46.166.139.20 -j DROP
To view blocked IP address:
iptables -L INPUT -v -n
Reference: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/