WebFixer24 Обсудить задачу

Ошибка базы данных WordPress: как найти причину и восстановить подключение

Разбираем, как проверить wp-config.php, MySQL/MariaDB, доступы и состояние базы данных, чтобы безопасно восстановить подключение WordPress.

Обновлено: Время чтения: около 12 минут

Сообщение Error establishing a database connection означает, что WordPress не смог подключиться к своей базе данных.

Для владельца сайта это выглядит пугающе: вместо страниц появляется одна строка об ошибке, иногда не открывается даже /wp-admin/. Но это ещё не означает, что база данных уничтожена или её нужно срочно восстанавливать.

Чаще проблема находится в одном из трёх мест:

  • WordPress использует неправильные реквизиты подключения;
  • сервер MySQL/MariaDB временно недоступен;
  • с самой базой или её таблицами действительно возникла проблема.

Поэтому сначала нужно определить, на каком именно этапе пропало соединение, и только потом что-либо ремонтировать.

Что вообще хранится в базе данных WordPress

WordPress состоит не только из файлов на сервере.

В базе данных находятся:

  • записи и страницы;
  • пользователи;
  • настройки сайта;
  • комментарии;
  • данные многих плагинов;
  • параметры темы;
  • меню и виджеты;
  • данные WooCommerce и других расширений.

Файлы WordPress при этом могут оставаться полностью исправными.

Если PHP-код не может подключиться к MySQL или MariaDB, WordPress просто не получает необходимые данные и не может нормально сформировать страницу.

Важно различать две ситуации: WordPress не может подключиться к базе данных и таблицы базы данных повреждены — это не одно и то же.

Поэтому сообщение Error establishing a database connection само по себе ещё не является поводом запускать восстановление таблиц.

↑ К оглавлению

Сначала вспомните, что менялось перед ошибкой

Если сайт недавно работал, попробуйте восстановить последовательность последних действий.

Особенно важно, если перед появлением ошибки:

  • меняли пароль пользователя базы данных;
  • переносили сайт;
  • восстанавливали резервную копию;
  • меняли хостинг или VPS;
  • редактировали wp-config.php;
  • меняли настройки MySQL/MariaDB;
  • создавали новую базу или нового пользователя;
  • выполняли работы на сервере.

Если ошибка возникла сразу после конкретного изменения, начинать стоит именно с него.

Перед серьёзными действиями с базой желательно сохранить текущее состояние сайта. Если MySQL ещё доступен — сделать свежий дамп базы. Файлы WordPress также стоит сохранить отдельно.

Особенно осторожно нужно действовать с интернет-магазинами и сайтами, где постоянно появляются новые заказы, заявки или пользователи: старый backup может не содержать самые свежие данные.

↑ К оглавлению

Проверьте настройки базы в wp-config.php

Основные параметры подключения WordPress находятся в файле:

wp-config.php

Нас интересуют четыре значения:

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

Они означают:

  • DB_NAME — имя базы данных;
  • DB_USER — пользователь MySQL/MariaDB;
  • DB_PASSWORD — пароль этого пользователя;
  • DB_HOST — адрес сервера базы данных.

Если хотя бы один параметр неверен, WordPress не сможет установить соединение.

Но не нужно менять все четыре значения сразу. Сначала сравните их с реальными настройками базы в панели хостинга или конфигурации сервера.

И важный момент: не публикуйте содержимое wp-config.php целиком в форумах, чатах или скриншотах. В нём находятся реальные данные доступа к базе и другие чувствительные параметры сайта.

↑ К оглавлению

Ошибка появилась после смены пароля базы данных

Это один из самых простых и одновременно распространённых сценариев.

Например, пароль пользователя MySQL изменили в панели хостинга. Сам WordPress об этом автоматически не узнает.

В wp-config.php при этом остаётся старое значение:

define( 'DB_PASSWORD', 'old-password' );

В результате MySQL уже ждёт новый пароль, а WordPress продолжает отправлять старый.

Если проблема появилась именно после смены пароля, нужно проверить соответствие DB_PASSWORD текущему паролю пользователя базы.

Но сначала убедитесь, что редактируется правильный wp-config.php, особенно если на сервере находится несколько копий сайта.

↑ К оглавлению

Почему DB_HOST не всегда localhost

В большинстве простых конфигураций встречается:

define( 'DB_HOST', 'localhost' );

Но localhost — не универсальное значение.

Некоторые хостинги используют отдельный адрес сервера базы данных, например hostname вида:

mysql.example-host.ru

В других конфигурациях может требоваться порт:

localhost:3307

или другой способ подключения.

После переноса сайта DB_HOST нередко остаётся от старого сервера.

Поэтому не стоит без причины заменять localhost на 127.0.0.1 или наоборот. Сначала нужно выяснить, какое значение действительно требуется в текущей конфигурации. Если ошибка появляется именно в phpMyAdmin, полезно также проверить user@host, способ подключения и доступ MySQL/MariaDB.

Если сайт находится на обычном хостинге, эту информацию обычно можно посмотреть в панели управления. На VPS — в конфигурации MySQL/MariaDB и самого приложения.

↑ К оглавлению

Проверьте, работает ли MySQL или MariaDB

Если реквизиты подключения правильные, следующий вопрос — доступен ли вообще сервер базы данных.

На VPS MySQL или MariaDB может:

  • остановиться;
  • не запуститься после перезагрузки;
  • завершаться с ошибкой;
  • не принимать новые подключения;
  • упираться в ограничения по ресурсам;
  • перестать работать из-за заполненного диска.

На обычном хостинге возможны:

  • временный сбой сервера БД;
  • превышение лимитов;
  • ограничения аккаунта;
  • проблемы на стороне самого хостинг-провайдера.

Поэтому ошибка подключения к базе не всегда означает неисправность WordPress.

Если сервер MySQL не работает, изменение wp-config.php, отключение плагинов или восстановление таблиц не решат проблему.

↑ К оглавлению

Почему ошибка то появляется, то исчезает

Очень полезный диагностический признак — плавающая ошибка.

Например:

  1. открываете сайт — ошибка базы данных;
  2. обновляете страницу — сайт работает;
  3. через несколько минут ошибка появляется снова.

В такой ситуации маловероятно, что виноват неправильный пароль. Пароль не становится правильным после нажатия F5.

Стоит проверить:

  • нагрузку на сервер;
  • количество соединений к MySQL;
  • память;
  • свободное место на диске;
  • стабильность сервера БД;
  • ограничения тарифного плана хостинга.

Если проблема возникает только во время пиков нагрузки, диагностика уже должна идти прежде всего на уровне MySQL и сервера.

↑ К оглавлению

Ошибка базы данных после переноса WordPress

После миграции сайта проблемы с подключением встречаются особенно часто.

Файлы можно перенести правильно, базу импортировать успешно, но WordPress всё равно покажет ошибку, если:

  • в wp-config.php осталось старое имя базы;
  • остался старый пользователь;
  • пароль не соответствует новому серверу;
  • указан старый DB_HOST;
  • пользователь MySQL не создан;
  • пользователь создан, но ему не выданы необходимые права на эту базу;
  • импорт базы завершился с ошибкой.

Поэтому после переноса полезно проверять цепочку целиком:

WordPress
↓
wp-config.php
↓
пользователь MySQL
↓
права пользователя
↓
нужная база данных

Если каждый элемент этой цепочки соответствует новой конфигурации, тогда уже имеет смысл искать проблему глубже.

↑ К оглавлению

А если база действительно повреждена

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

Но ремонт таблиц — это не первый шаг при обычном Error establishing a database connection.

WordPress имеет встроенный механизм ремонта базы. Для его включения в wp-config.php можно временно добавить:

define( 'WP_ALLOW_REPAIR', true );

После этого становится доступна служебная страница:

/wp-admin/maint/repair.php

Там WordPress предлагает восстановление и оптимизацию базы.

Но здесь есть важный нюанс.

При включённом WP_ALLOW_REPAIR эта страница может использоваться без обычной авторизации в административной панели. Поэтому опцию следует включать только на время необходимой процедуры. После завершения ремонта строку define( 'WP_ALLOW_REPAIR', true ); нужно удалить или отключить. Не оставляйте этот режим постоянно включённым на рабочем сайте.

↑ К оглавлению

Когда WP_ALLOW_REPAIR не поможет

Встроенный ремонт предназначен для проблем с таблицами.

Он не исправит ситуацию, если:

  • в wp-config.php указан неправильный пароль;
  • неверно задано имя базы;
  • ошибочно указан DB_HOST;
  • пользователь MySQL не имеет доступа;
  • MySQL/MariaDB вообще не запущен;
  • сервер базы данных недоступен;
  • закончилось место на сервере.

Это одна из причин, почему не стоит начинать диагностику с repair-инструмента.

Сначала выясните: WordPress вообще может установить соединение с сервером БД или нет?

И только затем решайте, требуется ли ремонт самих таблиц.

↑ К оглавлению

Что делать, если ошибка возникает только в wp-admin или при отдельных действиях

Иногда обычные страницы сайта работают, но ошибка появляется при:

  • входе в /wp-admin/;
  • сохранении записи;
  • обновлении настроек;
  • оформлении заказа;
  • выполнении конкретной операции плагина.

Это уже отличается от ситуации, когда WordPress полностью потерял соединение с БД.

Если большая часть сайта продолжает работать, значит подключение к базе как минимум существует.

Тогда проблема может находиться:

  • в конкретном SQL-запросе;
  • отдельной таблице;
  • плагине;
  • пользовательском коде;
  • нагрузке;
  • таймауте;
  • конкретной операции записи в базу.

В такой ситуации не нужно сразу менять пароль базы или запускать восстановление всех таблиц.

Сначала стоит определить действие, при котором происходит сбой.

↑ К оглавлению

Где искать ошибку, если WordPress ничего полезного не показывает

При проблемах с базой одной диагностики WordPress иногда недостаточно.

Полезная информация может находиться в:

  • PHP error log;
  • логах MySQL или MariaDB;
  • системных журналах VPS;
  • панели хостинга;
  • журнале веб-сервера;
  • сообщениях службы MySQL/MariaDB.

На собственном сервере также стоит проверить:

  • запущена ли служба БД;
  • сколько свободного места осталось;
  • хватает ли оперативной памяти;
  • нет ли постоянных рестартов MySQL;
  • не достигнут ли лимит подключений.

WP_DEBUG полезен для многих ошибок WordPress, но при полном отсутствии подключения к базе причина нередко находится уже ниже — на уровне самого MySQL/MariaDB или сервера.

Если параллельно возникает критический сбой WordPress, полезно посмотреть что делать при критической ошибке WordPress.

↑ К оглавлению

Что не стоит делать с базой WordPress наугад

База данных — не лучшее место для экспериментов методом перебора.

Не стоит:

  • удалять таблицы, чтобы WordPress «создал их заново»;
  • импортировать старый backup поверх текущей базы без понимания последствий;
  • менять одновременно DB_NAME, DB_USER, DB_PASSWORD и DB_HOST;
  • выдавать реквизиты базы посторонним;
  • отправлять кому-либо полный wp-config.php;
  • запускать массовые операции repair/optimize без причины и резервной копии;
  • переустанавливать WordPress, пока причина не установлена;
  • оставлять WP_ALLOW_REPAIR постоянно включённым;
  • удалять текущую базу до проверки резервной копии.

Особенно опасно восстанавливать старый дамп на живом магазине.

Например, в backup вчерашнего дня могут отсутствовать сегодняшние:

  • заказы;
  • оплаты;
  • пользователи;
  • изменения каталога;
  • заявки.

Поэтому «просто восстановить копию» иногда означает исправить сайт ценой потери свежих данных.

↑ К оглавлению

Если ошибка базы появилась вместе с ошибкой 500

Иногда вместо понятного сообщения о базе сервер возвращает 500 Internal Server Error.

Тогда полезно проверить и PHP/server logs, потому что первоначальная проблема могла возникнуть ещё до нормальной обработки WordPress.

Смотрите также: ошибка 500 в WordPress — как найти причину и восстановить сайт.

Если сбой появился после изменения или обновления, пригодится исправление WordPress после обновления.

↑ К оглавлению

Когда лучше остановиться и не экспериментировать на рабочем сайте

Самостоятельная диагностика разумна, если есть резервная копия и вы понимаете, какие изменения выполняете.

Но лучше не продолжать эксперименты на production, если:

  • это WooCommerce-магазин;
  • сайт продолжает принимать заявки или регистрации;
  • нет свежего backup;
  • MySQL не запускается;
  • база большая и содержит важные данные;
  • проблема появилась после миграции;
  • есть подозрение на повреждение таблиц;
  • ошибка то появляется, то исчезает;
  • восстановление старого дампа может привести к потере свежих данных.

В таких случаях правильный порядок обычно такой:

сохранить доступные данные → определить источник сбоя → выполнить точечное исправление → проверить сайт.

WebFixer24 может провести диагностику подключения WordPress к базе данных, проверить wp-config.php, MySQL/MariaDB и состояние таблиц и исправить причину сбоя без ненужной переустановки сайта.

↑ К оглавлению

Частые вопросы

Что означает Error establishing a database connection в WordPress?

WordPress не смог установить соединение с базой данных. Причиной могут быть неправильные параметры в wp-config.php, недоступность MySQL/MariaDB, проблемы с пользователем базы или сервером. Само сообщение ещё не означает, что таблицы базы повреждены.

Где WordPress хранит пароль от базы данных?

Данные подключения обычно находятся в файле wp-config.php. Пароль задаётся в параметре DB_PASSWORD. Этот файл содержит чувствительные данные, поэтому его содержимое не следует публиковать или отправлять посторонним.

Почему WordPress перестал подключаться к базе, хотя раньше всё работало?

Причиной может быть смена пароля MySQL, остановка сервера БД, проблемы хостинга, исчерпание ресурсов, заполненный диск или изменение серверной конфигурации. Если ошибка появляется периодически, стоит особенно внимательно проверить состояние MySQL и нагрузку.

Что делать, если после переноса сайта появилась ошибка базы данных?

Проверьте DB_NAME, DB_USER, DB_PASSWORD и DB_HOST в wp-config.php, наличие нужной базы на новом сервере, создание пользователя MySQL и его права. Также убедитесь, что импорт базы действительно завершился успешно.

Можно ли восстановить повреждённую базу WordPress?

В WordPress есть встроенный механизм восстановления таблиц через WP_ALLOW_REPAIR, но применять его следует только тогда, когда есть основания подозревать повреждение таблиц. Он не исправит неправильный пароль или недоступный сервер MySQL.

Безопасно ли использовать WP_ALLOW_REPAIR?

Использовать его можно временно для диагностики и восстановления таблиц. Но после включения служебная страница ремонта не требует обычного входа в WordPress, поэтому после завершения процедуры WP_ALLOW_REPAIR необходимо сразу отключить или удалить из wp-config.php.

↑ К оглавлению

Нужна помощь с базой WordPress?

Можно заказать точечную диагностику подключения, настроек и состояния базы данных. Выберите удобный способ обращения:

Оформить через WebFixer24 Через платформу KWORK

Страница услуги по исправлению WordPress

↑ К оглавлению