Ошибка подключения к базе WordPress: что проверить?

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

С чего начать, если WordPress потерял связь с базой?

Запишите время появления ошибки и последнее изменение перед сбоем. Сайт переносили на другой сервер? Меняли пароль пользователя базы? Восстанавливали резервную копию? Такие события сужают поиск. Среди причин ошибки встречаются переезд на другой хостинг, смена пароля в панели, переполнение диска и недоступность MySQL у провайдера (источник: KalinkinDev, «Ошибка установки соединения с базой данных WordPress: причины и порядок проверки»).

Сама надпись ещё не доказывает повреждение базы. На этом этапе переустановка WordPress и восстановление старой копии преждевременны: сначала нужно понять, почему сайт потерял соединение.

1. Откройте панель хостинга и проверьте уведомления о сбоях или технических работах.
2. Посмотрите, существует ли нужная база данных и доступен ли инструмент управления ею.
3. Проверьте свободное место в аккаунте хостинга или на VPS.
4. Зафиксируйте точный текст ошибки из журнала сайта за время сбоя.

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

Как проверить параметры базы в wp-config.php?

Откройте wp-config.php в каталоге нужной установки WordPress. Перед правками сохраните копию файла в закрытом месте вне публичного каталога сайта: внутри есть пароль к базе. На сервере с несколькими сайтами сначала убедитесь, что редактируете файл именно того домена, который выдаёт ошибку.

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

• DB_NAME — имя базы, к которой должен подключаться сайт.
• DB_USER — пользователь базы данных, а не логин от панели хостинга.
• DB_PASSWORD — действующий пароль этого пользователя.
• DB_HOST — адрес сервера базы данных; в отдельных конфигурациях он также содержит порт или путь к сокету.

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

Если пароль неизвестен, не меняйте его сразу: сначала выясните, какие приложения используют эту учётную запись. Новый пароль придётся указать в каждом из них. После согласованной смены обновите DB_PASSWORD и сохраните кавычки и синтаксис PHP в строке настройки.

Проверьте также, связан ли пользователь с нужной базой и есть ли у него права на работу с ней. Совпадение имени и пароля ещё не гарантирует доступ. При этом выдавать пользователю сайта административные права на весь сервер MySQL не требуется.

Что проверить на хостинге и на VPS?

На обычном хостинге начните с лимита диска и статуса базы в панели. Перезапуск MySQL обычно относится к зоне ответственности провайдера. В обращении укажите домен, время сбоя и результаты уже выполненных проверок; пароль от базы в сообщение не вставляйте.

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

1. Проверьте состояние службы MySQL или MariaDB через панель управления либо штатные инструменты операционной системы.
2. Посмотрите свободное место на разделе, где база хранит данные, и на разделе для временных файлов.
3. Проверьте доступную память и сообщения системы о принудительной остановке процессов.
4. Откройте журнал базы данных и найдите записи, совпадающие по времени со сбоем.
5. Если база находится на отдельном сервере, проверьте доступ к её адресу и порту со стороны веб-сервера.

Не запускайте команды перезапуска из случайной инструкции: имя службы и способ управления зависят от системы. Сначала сохраните сообщения об ошибке. Если база остановилась из-за заполненного раздела, один перезапуск не устранит причину.

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

Когда соединение работает, но запросы зависают под нагрузкой, отдельно исследуют дисковую подсистему. Для этого пригодится проверка скорости диска на VPS перед размещением базы данных. Такой тест помогает оценить задержки чтения и записи, но не исправит неверный пароль.

Как восстановить работу и проверить результат?

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

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

К восстановлению из резервной копии переходят, когда есть признаки повреждения или потери данных и понятна причина сбоя. До этого проверьте дату копии и возможность её прочитать. Откат базы заменяет текущее состояние старым, поэтому отдельно оцените, какие заказы или изменения появились после создания копии.

Если ошибка возникла после обновления, повторите проблемное действие на staging-копии сайта на VPS. Тестовая копия позволяет проверить обновление отдельно от рабочего сайта. Перед запуском отключите в ней реальные платежи и отправку уведомлений.

Для профилактики уточните, кто следит за свободным местом и доступностью базы, кто получает уведомления и кто проверяет восстановление из бэкапа. Эти обязанности стоит учитывать при подборе сервера и сравнении провайдеров. Услуга администрирования полезна именно понятным перечнем работ; состав managed-хостинга нужно проверять в условиях конкретного тарифа.

Типичные ошибки при восстановлении WordPress

• Менять несколько настроек одновременно. Сохраните исходные значения и проверяйте результат после каждой правки.
• Сразу увеличивать ресурсы VPS. Сначала найдите причину в журнале: дополнительная память не исправит ошибку авторизации.
• Запускать восстановление таблиц при любом сообщении о соединении. Сначала подтвердите доступ к серверу и наличие признаков повреждения.
• Отправлять поддержке полный wp-config.php. Передавайте текст ошибки и параметры без пароля; секреты удаляйте также со снимков экрана.
• Возвращать старую резервную копию без проверки. Сначала определите, какие актуальные данные она заменит.

Следующий шаг на две минуты: откройте раздел баз данных в панели хостинга и запишите, доступна ли нужная база и какой адрес подключения указан для неё.