Error establishing a database connection у WordPress: причини та покрокове виправлення

Повідомлення Error establishing a database connection означає, що WordPress не зміг встановити або зберегти потрібне з’єднання з MySQL чи MariaDB. Браузер не показує точну причину: однаковий екран з’являється через неправильний пароль, недоступний сервер бази, помилковий DB_HOST, відсутні права, перевищення лімітів або пошкодження таблиць.

Головний ризик — діяти навмання. Заміна файлів WordPress, перевстановлення плагінів або імпорт старої бази рідко є правильним першим кроком. На сайті з формами чи WooCommerce необережне відновлення може стерти заявки й замовлення, які з’явилися після резервної копії.

Якщо сайт приносить продажі, а доступу до журналів і резервних копій немає, безпечніше передати інцидент у межах технічної підтримки сайту. Для самостійної діагностики використовуйте послідовність нижче й фіксуйте кожну зміну.

Як WordPress підключається до бази

Контент WordPress не зберігається лише у файлах. Сторінки, записи, користувачі, налаштування, товари, замовлення та значна частина даних плагінів містяться в базі. Під час запиту WordPress читає чотири основні параметри з wp-config.php:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

Далі PHP-код звертається до вказаного сервера, MySQL перевіряє користувача та пароль, визначає дозволені джерело й базу, а потім приймає запити до таблиць. Збій на будь-якому етапі може дати однакове загальне повідомлення.

Не вставляйте реальні паролі у скриншоти, чат або заявку до підтримки. Якщо секрет уже опубліковано, змініть його й одразу синхронізуйте нове значення в wp-config.php.

Карта основних причин

Код відповіді й заголовки проблемної URL можна перевірити через інструменти BB STUDIO. Це допомагає відрізнити помилку застосунку від кешованої сторінки, редиректу чи відповіді проксі.

Перші 15 хвилин: безпечний порядок

1. Відкрийте сайт у приватному вікні та з іншої мережі.
2. Запишіть точний час появи, URL і останню відому зміну.
3. Перевірте головну, одну внутрішню сторінку, /wp-admin/ і, за наявності, health/status панель хостингу.
4. Не очищайте всі кеші й не імпортуйте копію до збереження поточного стану.
5. Завантажте wp-config.php і експорт бази, якщо панель ще дає доступ.
6. Перевірте, чи працюють інші сайти, що використовують той самий сервер бази.
7. Відкрийте журнал MySQL/MariaDB, PHP і системні події за відповідний час.
8. Тестуйте одну гіпотезу за раз.

Схожий екран не завжди означає ту саму проблему, що й помилка 500 у WordPress. Код 500 частіше пов’язаний із виконанням PHP або конфігурацією вебсервера, тоді як database connection error конкретніше вказує на етап доступу до бази.

Крок 1. Визначте масштаб проблеми

Не працює один сайт

Спочатку перевіряйте його wp-config.php, базу, користувача та права. Якщо інші проєкти на тому самому хостингу працюють, повне падіння сервера менш імовірне.

Не працюють усі сайти

Коли кілька незалежних інсталяцій одночасно втрачають базу, перевіряйте статус MySQL/MariaDB, перевантаження, диск, мережу між вебсервером і базою та роботи провайдера.

Помилка періодична

Якщо оновлення сторінки інколи допомагає, реквізити, імовірно, правильні. Шукайте вичерпання підключень, перезапуски MySQL, блокування, довгі запити, нестачу пам’яті, проблеми диска або нестабільну мережу. Не маскуйте такий інцидент автоматичним перезавантаженням: потрібна першопричина.

Помилка виникає лише під навантаженням

Порівняйте час збою з рекламними кампаніями, імпортом товарів, резервним копіюванням, cron, масовою розсилкою та бот-трафіком. Хороший хостинг для сайту має не лише достатній тариф, а й доступ до метрик, журналів і відновлення.

Крок 2. Перевірте wp-config.php

Порівнюйте параметри не зі старим листом або локальною копією, а з актуальними даними панелі хостингу.

DB_NAME

Назва повинна збігатися символ у символ. На shared hosting до неї часто додається префікс акаунта. Після перенесення нова база може мати іншу назву, навіть якщо домен не змінився.

DB_USER

Користувач бази — не обов’язково логін WordPress, FTP чи панелі. Переконайтеся, що він існує і прив’язаний саме до потрібної бази.

DB_PASSWORD

Пароль чутливий до регістру та спеціальних символів. Помилка часто з’являється після зміни пароля в панелі без оновлення wp-config.php. Не замінюйте символи «типографськими» лапками в редакторі.

DB_HOST

localhost підходить не завжди. Провайдер може використовувати окремий hostname, IP, порт або socket. Значення може виглядати як db.example.host:3306. Після міграції не копіюйте старий DB_HOST автоматично.

Синтаксис і зайві символи

Перевірте звичайні одинарні лапки, крапку з комою та відсутність випадкових переносів. Редагуйте текстовим редактором без форматування. Перед зміною створіть копію wp-config.php поза публічною директорією.

Крок 3. Перевірте реквізити окремим підключенням

Якщо маєте SSH, використовуйте стандартний клієнт MySQL із тими самими host, user і database, але не додавайте пароль безпосередньо до команди, якщо він потрапить в історію shell. На керованому хостингу скористайтеся штатним інструментом або попросіть провайдера перевірити з’єднання з вебвузла.

Результат звужує пошук:

• Access denied for user — неправильний пароль, користувач, дозволений host або права;
• Unknown database — помилкова назва чи видалена база;
• Can't connect to MySQL server — неправильний host/port, сервер не слухає або мережевий блок;
• Connection refused — служба не працює або порт недоступний;
• timeout — мережа, firewall, перевантаження чи завислий сервер.

Якщо окреме підключення працює, а WordPress — ні, порівняйте середовище PHP, фактичний файл конфігурації, db.php drop-in і кастомні змінні середовища.

Крок 4. Перевірте користувача й права

Правильний пароль не гарантує доступ до потрібної бази. MySQL враховує поєднання користувача та джерела підключення. Після перенесення користувач може існувати, але не бути доданим до нової бази або не мати потрібних привілеїв.

На shared hosting найнадійніший порядок:

1. перевірити зв’язок «користувач → база» у панелі;
2. повторно призначити дозволи штатним інтерфейсом;
3. не давати глобальні права на всі бази;
4. після зміни перевірити читання й запис тестовою дією WordPress;
5. зафіксувати, що саме змінилося.

Не копіюйте випадкові GRANT ALL команди з форуму на production. Надмірні права збільшують наслідки компрометації, а неправильний host у grant усе одно не дасть підключитися.

Крок 5. Перевірте стан MySQL/MariaDB і ресурсів

Коли конфігурація правильна, перевіряйте інфраструктуру:

• чи запущено службу бази;
• чи слухає вона потрібний порт або socket;
• чи є вільне місце та inodes;
• чи не вичерпано ліміт одночасних з’єднань;
• чи вистачає пам’яті;
• чи немає циклу перезапусків;
• чи доступна база з вебсервера;
• чи не блокує firewall потрібний маршрут;
• чи не закінчилася квота акаунта.

Для періодичного збою порівняйте графіки CPU, RAM, disk I/O і connections із точним часом помилки. Середнє навантаження за добу може приховати короткий пік, який зупиняє checkout.

Крок 6. Перевірте таблиці й оновлення бази

Якщо з’єднання встановлюється, але WordPress повідомляє, що окремі таблиці недоступні або потребують відновлення, не поспішайте запускати repair для всієї бази. Спочатку зробіть поточний dump і перевірте журнали.

WordPress має режим ремонту:

define( 'WP_ALLOW_REPAIR', true );

Після цього доступна службова сторінка /wp-admin/maint/repair.php. Вона може працювати без входу, тому константу потрібно видалити одразу після завершення. Repair не відновлює видалені записи, не замінює резервну копію і не виправляє апаратний чи файловий збій сервера.

Перед ремонтом з’ясуйте:

• які саме таблиці пошкоджені;
• який engine вони використовують;
• чи є свіжа копія;
• чи вистачає диска для операції;
• чи не триває запис замовлень;
• чи немає реплікації або керованих обмежень провайдера.

Для складної бази краще виконувати перевірку на копії або staging. Невдалий repair на єдиній production-базі може погіршити відновлення.

Крок 7. Перевірте міграцію та змінні середовища

Помилка після перенесення часто виникає не через WordPress, а через неповну карту залежностей. Перевірте:

• чи імпортовано базу до потрібного сервера;
• чи створено користувача й призначено права;
• чи змінився DB_HOST або порт;
• чи використовує deployment секрети з .env або панелі;
• чи не завантажується інший wp-config.php;
• чи перенесено wp-content/db.php від старого хостингу;
• чи не залишився зовнішній object cache із недійсними параметрами;
• чи доступний приватний database endpoint із нового вебвузла.

Професійна розробка сайту має передбачати документацію середовища, контрольоване перенесення і тест відновлення, а не лише копіювання файлів.

Окремий сценарій для WooCommerce

У магазині база змінюється постійно: замовлення, статуси оплати, залишки, кошики, сесії та вебхуки можуть з’являтися щохвилини. Тому відкат усієї бази до вчорашньої копії може повернути сайт, але втратити нові продажі.

Перед відновленням:

1. переведіть магазин у контрольований режим обслуговування, якщо це можливо;
2. збережіть поточну базу, навіть якщо вона частково пошкоджена;
3. перевірте журнал платіжного шлюзу й кабінет еквайрингу;
4. випишіть замовлення, створені після контрольної копії;
5. визначте, чи потрібне точкове відновлення таблиць, а не повний rollback;
6. після запуску звірте оплати, замовлення, stock і листи.

Не просіть клієнта повторно оплатити, доки не перевірено статус транзакції. Відсутність order у WordPress не означає, що банк не списав кошти.

Коли проблема пов’язана з безпекою

Зміна database password без відома власника, невідомий користувач, модифікований wp-config.php, сторонній db.php, нові cron-задачі або різкий сплеск запитів можуть вказувати на компрометацію.

У такому випадку недостатньо повернути старий пароль. Потрібно:

• зберегти журнали та поточний стан;
• змінити доступи до хостингу, SSH/SFTP, бази та WordPress;
• перевірити адміністраторів і ключі доступу;
• просканувати файли й порівняти ядро;
• перевірити persistence у plugins, mu-plugins, cron і drop-ins;
• оновити salts;
• з’ясувати початковий вектор атаки.

Вплив на SEO та рекламу

Короткий одноразовий збій зазвичай не руйнує позиції, але тривала або регулярна недоступність заважає скануванню, перериває покупки й марнує рекламний бюджет. Не віддавайте database error зі статусом 200 OK: для тимчасового збою коректніше контрольована відповідь 503 Service Unavailable, але її реалізація залежить від інфраструктури.

Після відновлення перевірте ключові URL, sitemap, robots, canonical, форми та checkout. Якщо інцидент тривав довго, проаналізуйте Search Console і логи. Системне SEO-просування включає технічний контроль доступності, а не лише роботу з ключовими словами.

Як перевірити, що сайт справді відновлено

Не обмежуйтеся відкриттям головної. Перевірте:

• вхід і збереження в адмінці;
• створення та редагування запису;
• форму заявки й доставку повідомлення;
• пошук, фільтри та особистий кабінет;
• кошик, checkout і тестову оплату;
• фонові завдання та webhooks;
• нові записи в MySQL/PHP logs;
• навантаження й кількість з’єднань;
• резервну копію після відновлення.

Потім зафіксуйте першопричину: «змінили пароль і не оновили конфіг», «вичерпано connections через імпорт», «після міграції лишився старий host». Запис «перезапустили сервер» описує дію, а не причину.

Як запобігти повторенню

1. Зберігайте конфігурацію та секрети за контрольованим процесом.
2. Робіть автоматичні копії файлів і бази в окреме сховище.
3. Регулярно тестуйте відновлення, а не лише факт створення архіву.
4. Моніторте HTTP-статус, MySQL connections, диск, CPU та RAM.
5. Встановіть сповіщення про вичерпання місця й недоступність бази.
6. Виконуйте оновлення та міграції зі staging і планом rollback.
7. Документуйте DB_HOST, порт, відповідального та контакти провайдера.
8. Обмежуйте права database user потрібною базою.
9. Не зберігайте production-паролі в публічних репозиторіях.
10. Після інциденту усувайте причину, а не лише симптом.

Орієнтири вартості планових і термінових робіт є на сторінці цін BB STUDIO, а приклади реалізованих рішень — у портфоліо.

Підсумковий чекліст

• зафіксовано час, URL і останню зміну;
• визначено, проблема постійна чи періодична;
• збережено поточні файли та базу;
• перевірено DB_NAME, DB_USER, DB_PASSWORD, DB_HOST;
• реквізити протестовано окремим підключенням;
• користувач прив’язаний до правильної бази;
• перевірено MySQL, порт, socket, диск і connections;
• repair запускався лише після копії;
• WP_ALLOW_REPAIR видалено після використання;
• для WooCommerce звірено оплати й нові замовлення;
• протестовано запис, форми, cron і checkout;
• створено нову контрольну копію;
• першопричину задокументовано.

Якщо помилка повертається або немає безпечної копії, зв’яжіться з BB STUDIO — локалізуємо збій, відновимо сайт і складемо план профілактики.

Висновок

Error establishing a database connection — не діагноз, а ознака того, що ланцюг «WordPress → мережа → MySQL → база» не спрацював. Найкоротший шлях до причини: визначити масштаб, зберегти поточний стан, перевірити чотири параметри wp-config.php, протестувати реквізити окремо, дослідити права й стан сервера, а вже потім ремонтувати таблиці або відновлювати копію.

Послідовність важливіша за кількість спроб. Одна підтверджена гіпотеза з журналом змін безпечніша за десять випадкових дій на production.

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

Що означає Error establishing a database connection?

WordPress не зміг підключитися до MySQL/MariaDB або втратив з’єднання під час роботи. Причиною можуть бути неправильні реквізити, недоступний сервер, права, ліміти чи пошкоджені таблиці.

Чи можна виправити помилку без доступу до адмінки?

Так. Потрібні доступ до файлів або SFTP, wp-config.php, панелі бази та журналів. Адмінка сама залежить від бази, тому її недоступність у цьому випадку очікувана.

Чи допоможе відновлення резервної копії?

Лише якщо проблема в даних або таблицях і копія справна. Якщо неправильний пароль, DB_HOST або MySQL недоступний, імпорт не усуне причину. Для магазину повний rollback може втратити нові замовлення.

Чи безпечно використовувати WP_ALLOW_REPAIR?

Використовуйте його лише після копії та за підтвердженої проблеми таблиць. Сторінка ремонту доступна без входу, тому константу потрібно видалити одразу після завершення.

Чому помилка з’являється лише інколи?

Періодичний збій частіше вказує на вичерпання з’єднань, навантаження, перезапуск MySQL, довгі запити, нестачу ресурсів або мережеву нестабільність, а не на постійно неправильний пароль.