Quick answer: "Error establishing a database connection" usually means one of four things: the database service is down (often OOM-killed or the disk is full), the credentials in the app config are wrong, the app points at the wrong host/socket, or MySQL hit its connection limit. Check systemctl status mariadb first — a stopped service is the cause in most cases.

Overview

The web server can be perfectly healthy while the site shows a database error — the app simply cannot reach or authenticate to MySQL/MariaDB/PostgreSQL. Diagnosis is a fixed four-step ladder: service → disk/memory → credentials → limits.

Before you start

  • SSH access and the app's DB settings file (wp-config.php, .env, etc.).

Step-by-step guide

  1. Is the database running?
    sudo systemctl status mariadb
    sudo journalctl -u mariadb -n 50
    If it is dead, the journal usually says why before you restart it.
  2. Check the two silent killers:
    df -h
    sudo dmesg -T | grep -i 'out of memory'
    A full disk or an OOM kill stops databases abruptly — fix those first or it will die again.
  3. Test the credentials the app actually uses:
    mysql -u APP_USER -p -h 127.0.0.1 APP_DB -e 'SELECT 1;'
    A rejection here means config drift — wrong password, user or database name.
  4. Socket vs TCP: localhost uses the Unix socket, 127.0.0.1 uses TCP. If the app expects a socket at a different path, connections fail while the server runs fine.
  5. Connection limit:
    mysql -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';"
    At the ceiling, raise max_connections moderately or fix the connection leak in the app.

Common issues

  • Nightly crashes: OOM during backups — classic on small plans; add swap or tune buffers.
  • Worked until a password change: the app config was not updated to match.
  • InnoDB recovery loop after full disk: free space, then restart; check the journal for corruption messages.

When to contact support

Support can confirm platform-side health (host, storage), but database contents and app configs are inside your unmanaged server. If the service will not start even with free disk and memory, open a ticket with the last 50 journal lines.

Frequently asked questions

The database was running fine and suddenly stopped — most likely cause?

On small servers the two classics are an out-of-memory kill during a load spike or backup, and a disk filled to 100%. Both stop MySQL abruptly and are visible in dmesg and df -h.

What is the difference between localhost and 127.0.0.1 in DB configs?

For MySQL clients, localhost means the Unix socket file while 127.0.0.1 forces TCP. If the expected socket path does not exist, localhost fails although the server itself runs fine.

Related articles

Need a hand? Contact Cloud2Y support →

Was this answer helpful? 0 Users Found This Useful (0 Votes)