„Грешка при свързване с базата данни“ в WordPress: какво означава

Какво казва съобщението

При всяка показана страница WordPress отваря връзка към своята база данни MySQL или MariaDB с четири данни, записани в wp-config.php, в корена на сайта:

define( 'DB_NAME', 'ime_na_bazata' );
define( 'DB_USER', 'potrebitel' );
define( 'DB_PASSWORD', 'parola' );
define( 'DB_HOST', 'localhost' );

„Грешка при свързване с базата данни“ означава, че тази връзка не е успяла. Четири причини я пораждат: данни за достъп, които вече не съвпадат, спрян или недостъпен сървър за бази данни, претоварен сървър или повредена база данни. Следващите раздели ги преминават от най-лесната за проверка до най-рядката.

1. Отговаря ли сървърът за бази данни?

• Страницата за състоянието на хостинг доставчика: там се обявява повреда или поддръжка на MySQL сървъра.
• Другите сайтове в същия акаунт: ако показват същата грешка по същото време, причината е в сървъра, а поправката е при хостинг доставчика.
• phpMyAdmin, от панела на хостинг доставчика: ако отваря базата и показва таблиците ѝ, сървърът работи и базата съществува.

Ако причината е в сървъра, отворете тикет при хостинг доставчика, като посочите часа, в който е започнала повредата, и точното съобщение. Междувременно сайтът може да остане такъв, какъвто е.

2. Верни ли са данните за достъп в wp-config.php?

Това е най-честата причина след преместване на сайта, смяна на паролата на базата в панела на хостинг доставчика или възстановяване. Сравнете четирите стойности от wp-config.php с раздела за бази данни при вашия хостинг доставчик:

• DB_NAME и DB_USER: много хостинг доставчици им добавят като префикс името на акаунта (akaunt_wordpress). Префиксът е част от името.
• DB_PASSWORD: при съмнение задайте нова парола за потребителя в панела и я въведете във файла.
• DB_HOST: localhost при много хостинг доставчици, но не при всички. Някои дават име на сървър или адрес, понякога последван от порт (:3306). Точната стойност е посочена в панела.
• Потребителят трябва да има права върху базата: в панела проверете дали потребителят е свързан с базата, с всички привилегии.

Парола, която съдържа апостроф ('), прекъсва PHP низа, който я огражда в wp-config.php. Поставете пред апострофа обратна наклонена черта (\') или изберете парола без апостроф.

Тествайте данните за достъп извън WordPress

WordPress показва общо съобщение. MySQL казва точно какво не е наред. Два начина да го попитате със стойностите от wp-config.php:

От командния ред, ако имате SSH достъп

mysql -h localhost -u potrebitel -p ime_na_bazata

С WP-CLI wp db check чете директно wp-config.php и проверява таблиците с тези данни за достъп.

С временен PHP файл

Качете този файл в корена на сайта под име, което е трудно за отгатване, отворете го в браузъра, след това веднага го изтрийте: той съдържа паролата на базата.

<?php
mysqli_report(MYSQLI_REPORT_OFF);
$vrazka = @mysqli_connect('localhost', 'potrebitel', 'parola', 'ime_na_bazata');
echo $vrazka ? 'Връзката е успешна' : 'Неуспех: ' . mysqli_connect_error();

Първият ред е важен: от PHP 8.1 насам неуспешна връзка по подразбиране хвърля изключение и страницата би останала бяла, вместо да покаже съобщението на MySQL.

3. Повредена база данни: инструментът за поправка

Когато данните за достъп са верни, но има повредени таблици, публичният сайт показва същото съобщение за грешка при свързване, а администрацията показва по-точно съобщение: „Една или повече таблици от базата данни не са на разположение. Базата данни може да се нуждае от поправка.“ WordPress предоставя инструмент за това. Добавете този ред в wp-config.php:

define( 'WP_ALLOW_REPAIR', true );

След това отворете https://www.vashiyat-sayt.com/wp-admin/maint/repair.php и пуснете „Поправка на базата от данни“. Премахнете реда веднага след края на поправката: докато той е там, тази страница е достъпна за всеки, без вход.

Преди всяка поправка направете експорт на базата (wp db export или раздела за експорт в phpMyAdmin). Ако поправката не успее, хостинг доставчикът може да възстанови базата от своите резервни копия.

4. Грешка, която идва и си отива: натоварването

Грешка, която се появява в определени часове и после изчезва сама, сочи претоварен сървър, а не грешна настройка. Най-честите причини:

• Пик на трафика, често от роботи: повтарящи се опити за вход през wp-login.php или xmlrpc.php, видими в журналите за достъп на хостинг доставчика.
• Лимитите на споделения хостинг: брой едновременни връзки или процеси, ограничен за всеки акаунт. Панелът на хостинг доставчика обикновено ги показва в раздела за потреблението на ресурси.
• Тежко разширение: статистики, журнали или планирани задачи, които пишат в базата при всяко посещение.

Поправките: блокирайте злоупотребяващите опити за вход, инсталирайте кеш на страници, изключете xmlrpc.php, ако никое приложение не го използва, и поискайте от хостинг доставчика журналите за периода с грешки.