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
2 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.


    [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'


    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): ''; port: 3306
    2019-10-17T07:16:42.715904Z 0 [Note]   - '' resolves to '';
    2019-10-17T07:16:42.715932Z 0 [Note] Server socket created on IP: ''.
    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...