„Błąd podczas nawiązywania połączenia z bazą danych” w WordPressie: przyczyna i naprawa

Co oznacza ten błąd

WordPress przy każdym żądaniu łączy się z bazą danych MySQL albo MariaDB; tam leżą wpisy, ustawienia, użytkownicy. Gdy połączenie się nie uda, zamiast strony pokazuje biały ekran z napisem „Błąd podczas nawiązywania połączenia z bazą danych” (w angielskiej wersji „Error establishing a database connection”). Serwer WWW i PHP działają, dlatego odpowiedź ma zwykle kod 200 albo 500, a sprawdzanie samego kodu HTTP nie zawsze to wyłapie.

Są dokładnie cztery możliwości: serwer bazy danych nie działa, działa, ale nie przyjmuje połączeń (limit, pełny dysk), dane logowania w wp-config.php są złe, albo baza istnieje, ale jej tabele są uszkodzone. Kolejność sprawdzania poniżej idzie od najczęstszej.

Częste przyczyny

1. MySQL/MariaDB zatrzymany. Najczęściej po tym, jak jądro zabiło proces z braku pamięci (OOM-killer) na małym VPS-ie, albo po nieudanej aktualizacji.
2. Pełny dysk. Baza nie może zapisać dziennika ani pliku tymczasowego i odrzuca połączenia; czasem zatrzymuje się całkiem.
3. Złe dane w wp-config.php. Po przeprowadzce, zmianie hasła w panelu albo zmianie hosta bazy: DB_NAME, DB_USER, DB_PASSWORD albo DB_HOST nie pasują.
4. Uszkodzone tabele. Po twardym restarcie albo pełnym dysku tabela wp_options albo wp_posts jest oznaczona jako „crashed”.
5. Limit połączeń. max_connections wyczerpany przez wtyczkę, atak na wp-login.php albo wolne zapytania, które trzymają połączenia.
6. Limit hostingu. Na hostingu współdzielonym serwer bazy stoi u dostawcy; przekroczony limit zapytań albo awaria po jego stronie.
7. Zły host bazy. localhost zamiast socketu, 127.0.0.1 zamiast nazwy zewnętrznego serwera, albo zmieniony port.

Jeśli odwiedzasz cudzą stronę

Nic do zrobienia; to problem serwera właściciela. Odśwież po minucie. Jeśli trwa, właściciel musi zajrzeć na serwer.

Jeśli to Twoja strona: najpierw sprawdź

Narzędzie Is it down? potwierdzi, że strona odpowiada komunikatem zamiast treści. Potem na serwerze albo hostingu z SSH:

# czy baza działa?
systemctl status mysql mariadb 2>/dev/null | grep -E 'service|Active'
sudo ss -tlnp | grep -E ':3306|mysqld'

# dysk i pamięć
df -h
df -i
free -m
sudo dmesg -T | grep -iE 'oom|killed process' | tail -n 10

# log bazy
sudo tail -n 50 /var/log/mysql/error.log

Potem sprawdź dane logowania dokładnie tak, jak robi to WordPress:

cd /var/www/przyklad.pl
grep -E "DB_(NAME|USER|PASSWORD|HOST)" wp-config.php
mysql -u NAZWA_UZYTKOWNIKA -p -h localhost NAZWA_BAZY -e 'SELECT 1;'

Access denied to złe dane (przyczyna 3). Can't connect to local MySQL server through socket to zatrzymana usługa (1). Too many connections to limit (5). Połączenie działa, a strona nie: tabele (4).

Z WP-CLI jeszcze prościej: wp db check wypisuje stan każdej tabeli, a wp config list pokazuje odczytane ustawienia.

Naprawy na własnym serwerze albo hostingu z SSH

1. Uruchom bazę danych

sudo systemctl start mariadb      # albo mysql
systemctl status mariadb
sudo journalctl -u mariadb -n 50 --no-pager

Jeśli nie startuje, dziennik mówi dlaczego: pełny dysk, uszkodzony plik ib_logfile, zły parametr w my.cnf. Po usunięciu przyczyny uruchom ponownie. Jeśli OOM-killer zabija bazę regularnie, zmniejsz innodb_buffer_pool_size albo liczbę procesów PHP-FPM, albo dołóż pamięci; sam restart to tylko odroczenie.

2. Zwolnij dysk

sudo journalctl --vacuum-size=200M
sudo du -xh /var --max-depth=2 2>/dev/null | sort -h | tail -n 15
sudo apt clean

Stare kopie zapasowe, logi i rozpędzony debug.log to zwykli winni. Nigdy nie usuwaj plików z /var/lib/mysql.

3. Popraw wp-config.php

define('DB_NAME',     'przyklad_wp');
define('DB_USER',     'przyklad_user');
define('DB_PASSWORD', 'tajne-haslo');
define('DB_HOST',     'localhost');

Hasło zmienisz po stronie bazy, jeśli nie pamiętasz starego:

ALTER USER 'przyklad_user'@'localhost' IDENTIFIED BY 'nowe-haslo';
FLUSH PRIVILEGES;

Na hostingu hasło i host bazy widać w panelu („Bazy danych MySQL”); host bywa inny niż localhost.

4. Napraw tabele

wp db repair
wp db optimize

Bez WP-CLI dopisz tymczasowo do wp-config.php linię define('WP_ALLOW_REPAIR', true);, otwórz https://przyklad.pl/wp-admin/maint/repair.php, uruchom naprawę i usuń linię po zakończeniu. Dla tabel InnoDB, których naprawa nie pomaga, przywróć kopię zapasową bazy.

5. Limit połączeń

SHOW VARIABLES LIKE 'max_connections';
SHOW PROCESSLIST;

Zabij wiszące zapytania, znajdź wtyczkę, która je tworzy, i ustaw limit zapytań na wp-login.php i xmlrpc.php (poradnik o błędzie 503). Podniesienie max_connections bez pamięci na nie tylko przesunie problem.

6. Zły host

Jeśli baza stoi na innej maszynie, sprawdź z serwera WWW: nc -zv -w 5 10.0.0.5 3306. Firewall, zmieniony adres albo bind-address = 127.0.0.1 w my.cnf na serwerze bazy blokują połączenie zdalne.

Gdy to problem dostawcy hostingu

Na hostingu współdzielonym serwer bazy należy do dostawcy. Jeśli dane w wp-config.php zgadzają się z panelem, a połączenie z konsoli SSH też zawodzi, wyślij:

Dzień dobry, moja strona przyklad.pl pokazuje „Błąd podczas nawiązywania połączenia z bazą danych” od około 07:50 UTC. Dane dostępowe w wp-config.php są zgodne z panelem, a połączenie testowe z konsoli zwraca „Can’t connect” (albo „Too many connections”). Czy serwer bazy danych mojego konta działa i czy nie został przekroczony limit?

Jak zapobiec następnemu

Baza zatrzymuje się po braku pamięci albo pełnym dysku, a oba widać wcześniej. Agent serwerowy pilnuje usługi MySQL/MariaDB, pamięci i dysków i wysyła alert, gdy usługa stanie albo dysk przekroczy próg; sprawdzanie słowa kluczowego w monitoringu stron wyłapuje komunikat błędu nawet przy kodzie 200. Awaria? Naprawiamy: Quick Fix restartuje zatrzymaną bazę po udanym teście jej konfiguracji i zwalnia miejsce na dysku w stałej cenie; dane dostępowe, uszkodzone tabele i limity porządkuje Deep Fix, przez całą dobę. Zobacz naprawa serwera i naprawa WordPressa na żądanie. Pokrewne poradniki: błąd 500 i błąd krytyczny WordPress.