Коротка відповідь: «Error establishing a database connection» зазвичай означає одне з чотирьох: сервіс БД лежить (часто після OOM-кіла чи повного диска), у конфізі застосунку неправильні облікові дані, застосунок дивиться не на той хост/сокет, або MySQL уперся в ліміт зʼєднань. Спершу перевірте systemctl status mariadb — зупинений сервіс є причиною в більшості випадків.

Огляд

Вебсервер може бути цілком здоровим, а сайт показуватиме помилку БД — застосунок просто не може достукатися чи автентифікуватися до MySQL/MariaDB/PostgreSQL. Діагностика — фіксована драбина з чотирьох сходинок: сервіс → диск/памʼять → облікові дані → ліміти.

Що потрібно мати

  • Доступ по SSH і файл налаштувань БД застосунку (wp-config.php, .env тощо).

Покрокова інструкція

  1. Чи працює база? 
    sudo systemctl status mariadb
sudo journalctl -u mariadb -n 50
    Якщо вона мертва, journal зазвичай каже чому ще до перезапуску.
  2. Перевірте двох тихих убивць: 
    df -h
sudo dmesg -T | grep -i 'out of memory'
    Повний диск чи OOM-кіл зупиняють бази раптово — спершу виправте це, інакше вона помре знову.
  3. Перевірте облікові дані, які реально використовує застосунок: 
    mysql -u APP_USER -p -h 127.0.0.1 APP_DB -e 'SELECT 1;'
    Відмова тут означає розсинхрон конфіга — не той пароль, користувач чи назва бази.
  4. Сокет чи TCP: localhost використовує Unix-сокет, 127.0.0.1 — TCP. Якщо застосунок чекає сокет за іншим шляхом, зʼєднання падають, хоча сервер працює.
  5. Ліміт зʼєднань: 
    mysql -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';"
    На стелі — помірно підніміть max_connections або виправте витік зʼєднань у застосунку.

Типові проблеми

  • Нічні падіння: OOM під час бекапів — класика на малих планах; додайте swap або зменшіть буфери.
  • Працювало до зміни пароля: конфіг застосунку не оновили відповідно.
  • Цикл відновлення InnoDB після повного диска: звільніть місце, потім перезапустіть; перегляньте journal на повідомлення про пошкодження.

Коли звертатися в підтримку

Підтримка може підтвердити здоровʼя платформи (хост, сховище), але вміст бази й конфіги застосунків — всередині вашого unmanaged-сервера. Якщо сервіс не стартує навіть із вільним диском і памʼяттю — відкрийте тикет з останніми 50 рядками journal.

Часті запитання

База працювала нормально і раптом зупинилася — найімовірніша причина?

На малих серверах дві класики: OOM-кіл під час сплеску навантаження чи бекапа та диск, заповнений на 100%. Обидва зупиняють MySQL раптово і видимі в dmesg та df -h.

Чим localhost відрізняється від 127.0.0.1 у конфігах БД?

Для клієнтів MySQL localhost означає Unix-сокет, а 127.0.0.1 примушує TCP. Якщо очікуваного файлу сокета немає, localhost не працює, хоча сам сервер повністю справний.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)

Найпопулярніші

VPS не відповідає: що робити

Коротка відповідь: Спершу перевірте статус послуги та стан живлення в Client Area, а потім...
Сайт не працює: перші кроки

Коротка відповідь: Рухайтеся ззовні всередину: переконайтеся, що сайт лежить для всіх, перевірте,...
Не вдається підключитися по SSH

Коротка відповідь: Спершу прочитайте точний текст помилки: timeout вказує на мережу чи фаєрвол,...
Помилка Connection refused

Коротка відповідь: «Connection refused» означає, що ваші пакети дійшли до сервера, але на цьому...
Помилка Permission denied (publickey)

Коротка відповідь: «Permission denied (publickey)» означає, що зʼєднання SSH працює, але сервер...