Ошибка подключения к базе данных WordPress — как исправить
Почему WordPress теряет базу данных
Ошибка возникает на этапе wp-db.php — самого первого подключения к MySQL. WordPress пробует mysqli_connect() с креденшелами из wp-config.php. Не вышло — белый экран.
Вот что ломается чаще всего, от простого к сложному.
DB_NAME, DB_USER, DB_PASSWORD и DB_HOST в корневом wp-config.php.systemctl status mysql или systemctl status mariadb. На shared-хостинге — в панели управления (ISPmanager, cPanel, Beget). Иногда сервис висит в статусе «starting» после перезагрузки сервера.df -h на VPS. На shared-хостингах место показывается в панели. Если занято >95% — база не стартует или работает с ошибками.wp_options и wp_posts — самые активно пишущиеся.DB_HOST = 'localhost', а на VPS может быть '127.0.0.1' или socket. На Beget — 'localhost', на Timeweb — тоже, на REG.RU иногда требует полный путь к сокету.Как исправить: пошагово
Шаг 1. Проверяем wp-config.php
Файл лежит в корне сайта. Откройте и найдите блок:
define( 'DB_NAME', 'имя_базы' );
define( 'DB_USER', 'пользователь' );
define( 'DB_PASSWORD', 'пароль' );
define( 'DB_HOST', 'localhost' );Сверьте с данными из панели хостинга. На Beget: «Управление базами MySQL» в ISPmanager. На Timeweb: «Базы данных» в личном кабинете. На REG.RU: раздел «MySQL» в панели хостинга.
Если недавно меняли пароль — проверьте, что в wp-config.php он новый. Старые сессии или кэш панели хостинга могут показывать устаревший пароль — создайте нового пользователя БД заново и пропишите, если сомневаетесь.
'localhost'. REG.RU иногда требует 'localhost:/var/run/mysqld/mysqld.sock' или просто IP 127.0.0.1. Если 'localhost' не работает — попробуйте '127.0.0.1'.Шаг 2. Проверяем — жива ли база вообще
Самый быстрый тест — PHP-скрипт на 5 строк. Создайте файл db-test.php в корне сайта:
<?php
$link = mysqli_connect('localhost', 'user', 'pass', 'dbname');
if (!$link) {
die('MySQL error: ' . mysqli_connect_error());
}
echo 'OK — MySQL works, DB selected';
Подставьте свои доступы из wp-config.php. Откройте https://ваш-сайт/db-test.php. Если пишет «OK» — база жива, проблема в чём-то другом. Если ошибка — читайте сообщение: оно скажет конкретную причину (неверный пароль, нет такой базы, сервер не найден).
Не забудьте удалить файл после проверки — в нём пароль открытым текстом.
Шаг 3. Ремонт таблиц
Если база жива, но часть таблиц повреждена — чиним через phpMyAdmin или консоль. В phpMyAdmin: выберите базу → отметьте все таблицы → внизу выпадающий список «Восстановить таблицы».
Через консоль MySQL:
mysqlcheck -u user -p --auto-repair dbnameЕсли сайт на WooCommerce или busy-блоге — глючит чаще всего wp_options. Её можно починить прицельно:
mysqlcheck -u user -p --auto-repair dbname wp_optionsШаг 4. Свободное место на диске
На VPS: df -h. Ищите строчку с / или /var/lib/mysql. Если Use% под 100 — чистите логи, временные файлы, кэш.
Быстрая очистка на Ubuntu/Debian:
apt-get clean
journalctl --vacuum-size=200M
rm -rf /tmp/*.tmpНа shared-хостингах Beget и Timeweb: в панели смотрите занятое место (обычно раздел «Тарифы и услуги» или «Статистика»). Если диск забит — удалите старые бэкапы, логи или расширьте тариф.
Шаг 5. Перезапуск MySQL
Если сервис висит в статусе failed или starting:
systemctl restart mysql
# или
systemctl restart mariadbПосле перезапуска проверьте статус: systemctl status mysql. Должен быть active (running). Если падает сразу — смотрите логи: tail -50 /var/log/mysql/error.log. Частая причина падения — битый ibdata1 (InnoDB) после жёсткой перезагрузки сервера.
Шаг 6. Если ничего не помогло — восстанавливаем из бэкапа
На Beget бэкапы лежат в ISPmanager → «Резервные копии». На Timeweb — в разделе «Бэкапы» панели. Скачайте последний дамп и залейте через phpMyAdmin или консоль:
mysql -u user -p dbname < backup.sqlПеред заливкой дампа — сохраните текущее состояние на всякий случай:
mysqldump -u user -p dbname > broken_state.sqlКак проверить, что всё сработало
/wp-admin/) пускает. 3. Откройте пару страниц, создайте тестовую запись — всё пишется в базу и отображается.Дополнительно проверьте логи WordPress: /wp-content/debug.log. Включите на время отладку в wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
Если после починки в логах тишина — ошибка устранена.
Когда способ не сработает
- Физически убит диск на сервере. Без MySQL-дампа в другом месте данные не вернуть. Мораль: храните бэкапы вне сервера.
- База утеряна хостингом. На дешёвых тарифах бэкапы могут не делаться. Перед любыми правками wp-config.php делайте дамп.
- Сайт взломан и база зашифрована. Ошибка соединения может быть следствием того, что злоумышленник дропнул таблицы или сменил префикс. Здесь поможет только восстановление из чистого бэкапа с последующей сменой всех паролей.
- Не хватает оперативной памяти. Если на VPS 512MB RAM и MySQL падает по OOM — ошибка соединения будет возвращаться после каждого рестарта. Добавьте swap или расширьте тариф.
Частые вопросы
wp_postmeta), главная может работать, а страницы записей — падать. Ищите ошибки в debug.log — там будет название запроса и таблицы, которая сломалась.DB_HOST = 'localhost'. Если локально был Docker/MAMP — там мог быть нестандартный хост типа db:3306. Замените на 'localhost'.define( 'WP_ALLOW_REPAIR', true );. Затем откройте /wp-admin/maint/repair.php. Выберите «Repair Database» или «Repair and Optimize». После починки — обязательно удалите строчку из wp-config.php.База лежит, а поддержка хостинга не отвечает?
Подключусь, диагностирую причину и восстановлю сайт — обычно за час.
