Question

Error establishing a database connection - DO 1 click wordpress installation.

Posted October 17, 2019 2.9k views
MySQLWordPressDatabases

Hello there! :)

I used to run the very same website on a droplet I set up myself in 2017. I decided to trash the project in early 2019 and recovered it on a DO 1 click wordpress installation about 2 months ago.

Since then I’m getting the Error establishing a database connection after the server runs for a few days. It’s easily fixed by restarting the droplet which indicates some sort of “misconfiguration” in the DB settings.

Does any of you have a clue on what it might be and how to resolve it? The website is really in its bare state as far as content goes and has no visitors at all.

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
3 answers

Hello @xfabioreims ,

This sounds indeed like some misconfiguration, network issues or resource issues. Could you please give some more logs, this will definitely help out solving this:

sudo tail /var/log/mysql/error.log
sudo tail /var/log/apache2/error.log

Thank you.

  • APACHE

    [Thu Oct 17 06:29:05.794345 2019] [mpm_prefork:notice] [pid 1016] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
    [Thu Oct 17 06:29:05.794360 2019] [core:notice] [pid 1016] AH00094: Command line: '/usr/sbin/apache2'
    [Thu Oct 17 07:16:17.281799 2019] [mpm_prefork:notice] [pid 1016] AH00169: caught SIGTERM, shutting down
    [Thu Oct 17 07:16:41.741696 2019] [mpm_prefork:notice] [pid 1024] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 configured -- resuming normal operations
    [Thu Oct 17 07:16:41.760813 2019] [core:notice] [pid 1024] AH00094: Command line: '/usr/sbin/apache2'
    

    MYSQL

    2019-10-17T07:16:42.133017Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
    2019-10-17T07:16:42.134905Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.27-0ubuntu0.18.04.1) starting as process 1018 ...
    2019-10-17T07:16:42.179799Z 0 [Note] InnoDB: PUNCH HOLE support available
    2019-10-17T07:16:42.179824Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
    2019-10-17T07:16:42.179827Z 0 [Note] InnoDB: Uses event mutexes
    2019-10-17T07:16:42.179831Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
    2019-10-17T07:16:42.179834Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    2019-10-17T07:16:42.179839Z 0 [Note] InnoDB: Using Linux native AIO
    2019-10-17T07:16:42.182146Z 0 [Note] InnoDB: Number of pools: 1
    2019-10-17T07:16:42.188543Z 0 [Note] InnoDB: Using CPU crc32 instructions
    2019-10-17T07:16:42.191137Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
    2019-10-17T07:16:42.268464Z 0 [Note] InnoDB: Completed initialization of buffer pool
    2019-10-17T07:16:42.295992Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
    2019-10-17T07:16:42.313290Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
    2019-10-17T07:16:42.316834Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 91529458
    2019-10-17T07:16:42.316850Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 91529467
    2019-10-17T07:16:42.316855Z 0 [Note] InnoDB: Database was not shutdown normally!
    2019-10-17T07:16:42.316858Z 0 [Note] InnoDB: Starting crash recovery.
    2019-10-17T07:16:42.550366Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2019-10-17T07:16:42.550388Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
    2019-10-17T07:16:42.550426Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
    2019-10-17T07:16:42.619208Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
    2019-10-17T07:16:42.619988Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
    2019-10-17T07:16:42.620003Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
    2019-10-17T07:16:42.620235Z 0 [Note] InnoDB: Waiting for purge to start
    2019-10-17T07:16:42.670389Z 0 [Note] InnoDB: 5.7.27 started; log sequence number 91529467
    2019-10-17T07:16:42.670560Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
    2019-10-17T07:16:42.671173Z 0 [Note] Plugin 'FEDERATED' is disabled.
    2019-10-17T07:16:42.714795Z 0 [Note] InnoDB: Buffer pool(s) load completed at 191017  7:16:42
    2019-10-17T07:16:42.715881Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
    2019-10-17T07:16:42.715895Z 0 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
    2019-10-17T07:16:42.715904Z 0 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
    2019-10-17T07:16:42.715932Z 0 [Note] Server socket created on IP: '127.0.0.1'.
    2019-10-17T07:16:42.796415Z 0 [Note] Event Scheduler: Loaded 0 events
    2019-10-17T07:16:42.796585Z 0 [Note] /usr/sbin/mysqld: ready for connections.
    Version: '5.7.27-0ubuntu0.18.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
    
    edited by MattIPv4
  • Due to DO marking my reply as spam and thus, not posting it, here is a pastebin link to the error logs after restarting the droplet to fix the “Error establishing connection to database”-error. After Restart Log

    Here is the log from the 16'th on which I presume the error occurred.

    Actual Error Log

    I hope it can provide you the inside you seek. Older logs also exist.

tail /var/log/syslog | grep “mysql” 

results in tail: cannot open ‘mysql’ for reading: No such file or directory

The syslog file is in /var/log but even changing it to that doesn’t result in a different error.

  • Allright, that is a weird error. Did you check the syntax again?

    Anyway, it doesn’t confirm my suspicious, but looking at the last error:

     0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
    

    This tells you you either:

    • Have no swap space setup, so whenever the RAM limit is reached the system can not put its pages in swap.
    • You do not have enough VRAM.

    You can solve this by upgrading your VM, and / or setting up swap for your machine.

    Hope this helps you, let me know.

    • https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

      would explain why swap is disabled by default. Would you still recommend enabling it?

      As for the VRAM. I’ve been running the exact same setup on two 5$ droplets before and am now running them on a single one.

      My memory usage on the droplet’s statistic website top out at 66.10%. I’d like to stress that the website is literally just a blank WordPress installation with a custom theme and 5 posts without any traffic outside of the one generated by me.

      In that regard, I’m curious how upgrading the droplet would prevent the error from repeating since it seems to just write the VRAM until it’s full. From my limited understanding it’d merely delay the occurrence of the problem.

      by Justin Ellingwood
      One of the easiest way of increasing the responsiveness of your server and guarding against out of memory errors in your applications is to add some swap space. In this guide, we will cover how to add a swap file to an Ubuntu 16.04 server. <$>[warning] [label...

Hello, all

This crash is most likely due to your system running out of memory. I’d suggest that you add a swap file to give yourself a bit more of a buffer. Check out this tutorial:

How To Add Swap on Ubuntu

You will most definitely need to upgrade your droplet as you’re running out of memory and your application/website needs more resources in order to continue to operate.

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