Error establishing a database connection — co oznacza i jak naprawić błąd w WordPress

„Error establishing a database connection” to jeden z najbardziej stresujących komunikatów, jakie może wyświetlić WordPress. Strona nagle znika, panel administracyjny też nie chce się załadować, a zamiast treści widzisz białą kartkę z jedną linią tekstu. Dobra wiadomość jest taka, że w 90% przypadków błąd ma banalną przyczynę i można go naprawić w kilka minut — o ile wiesz, gdzie szukać.

W tym poradniku pokazuję, co dokładnie oznacza ten błąd, skąd się bierze, jak go zdiagnozować oraz 7 konkretnych rozwiązań krok po kroku — od szybkiego sprawdzenia wp-config.php, przez reperację bazy danych, aż po sytuacje awaryjne, w których jedynym wyjściem jest przywrócenie kopii zapasowej.

Co oznacza „Error establishing a database connection”?

WordPress to aplikacja PHP, która przy każdej prośbie o stronę pyta bazę danych MySQL (lub MariaDB) o treść wpisów, ustawienia, menu, komentarze i setki innych rzeczy. Jeżeli WordPress nie może się z tą bazą dogadać — z jakiegokolwiek powodu — wyrzuca właśnie ten komunikat i przerywa ładowanie strony.

Mówiąc prościej: Twoja strona nie widzi bazy danych. Nie wie, czy baza padła, czy dane logowania są złe, czy serwer MySQL jest przeciążony. Dlatego diagnoza zawsze polega na wykluczaniu kolejnych możliwych przyczyn.

Jak WordPress łączy się z bazą — w pigułce

Cały proces sprowadza się do kilku linijek w pliku wp-config.php:

define( 'DB_NAME',     'nazwa_bazy' );
define( 'DB_USER',     'nazwa_uzytkownika' );
define( 'DB_PASSWORD', 'haslo_do_bazy' );
define( 'DB_HOST',     'localhost' );

Jeżeli którakolwiek z tych wartości jest niepoprawna, serwer MySQL nie działa, albo użytkownik bazy utracił uprawnienia — WordPress zwróci „Error establishing a database connection”.

7 najczęstszych przyczyn błędu

Zanim przejdziesz do napraw, warto wiedzieć, czego szukasz. Oto lista przyczyn w kolejności częstotliwości występowania:

1. Błędne dane dostępowe w wp-config.php — najczęstsza przyczyna po migracji strony na nowy serwer lub zmianie hasła do bazy.
2. Serwer MySQL nie działa lub jest przeciążony — zwłaszcza na współdzielonych hostingach w godzinach szczytu.
3. Uszkodzone tabele bazy danych — występuje po nagłych przerwach w zasilaniu serwera, błędach podczas aktualizacji lub importach plików SQL.
4. Przekroczony limit połączeń do MySQL (max_connections) — zbyt wiele wtyczek, kampania reklamowa, bot lub atak DDoS.
5. Brak wolnego miejsca na dysku — gdy partycja jest pełna, MySQL odmawia zapisu i strona przestaje działać.
6. Błędny prefix tabel ($table_prefix) — występuje zwykle po nieudanej migracji albo przenoszeniu bazy „na pałę”.
7. Zainfekowana strona lub atak — skrypty malware i boty potrafią zapchać MySQL setkami zapytań na sekundę.

Szybka diagnostyka — zanim zaczniesz naprawiać

Zanim otworzysz FTP i zaczniesz grzebać w plikach, zrób trzy rzeczy, które zaoszczędzą Ci mnóstwo czasu.

1. Sprawdź, czy błąd dotyczy także /wp-admin

Wejdź pod adres twojadomena.pl/wp-admin. Są trzy możliwe scenariusze:

• Ten sam błąd — problem jest po stronie bazy lub serwera MySQL.
• Inny komunikat: „One or more database tables are unavailable. The database may need to be repaired” — baza żyje, ale ma uszkodzone tabele. Przejdź od razu do sekcji „Naprawa bazy”.
• Panel ładuje się normalnie — rzadkie, ale możliwe; zajrzyj do wtyczek cache’ujących.

2. Włącz tryb debugowania WordPress

W wp-config.php ustaw:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Od tego momentu WordPress będzie zapisywał szczegółowe błędy do pliku wp-content/debug.log. Zobaczysz tam na przykład, czy problem leży w złym haśle, czy serwer MySQL nie odpowiada w ogóle.

3. Napisz szybki skrypt testowy PHP

Utwórz plik test-db.php w katalogu głównym WordPressa z taką zawartością:

<?php
$link = mysqli_connect('localhost', 'DB_USER', 'DB_PASSWORD', 'DB_NAME');
if (!$link) {
    die('Nie mogę się połączyć: ' . mysqli_connect_error());
}
echo 'Połączenie z bazą działa!';
mysqli_close($link);

Jeżeli ten skrypt wyrzuci błąd typu „Access denied” — masz złe dane. Jeżeli „Can’t connect to MySQL server” — problem jest po stronie serwera bazy, a nie Twojej strony.

Pamiętaj, aby usunąć plik test-db.php zaraz po diagnozie — przechowywanie haseł do bazy w publicznie dostępnym skrypcie to proszenie się o kłopoty.

7 sprawdzonych sposobów naprawy

1. Zweryfikuj dane w wp-config.php

Otwórz plik wp-config.php przez FTP lub menedżer plików w panelu hostingu i porównaj cztery stałe z danymi w panelu bazy danych (zazwyczaj sekcja „Bazy MySQL”):

define( 'DB_NAME',     'nazwa_bazy' );
define( 'DB_USER',     'uzytkownik_bazy' );
define( 'DB_PASSWORD', 'haslo' );
define( 'DB_HOST',     'localhost' );

Uwaga na trzy rzeczy:

• DB_HOST nie zawsze jest „localhost” — niektóre hostingi używają nazw typu mysql.serwer123.home.pl, sql.hostingasp.pl albo adresu IP. Sprawdź w panelu.
• Polskie znaki i białe spacje w haśle potrafią psuć połączenie — jeśli masz w haśle znaki specjalne, zmień je na czysto ASCII i zaktualizuj wp-config.php.
• Wielkość liter ma znaczenie — MySQL traktuje „MojaBaza” i „mojabaza” jako różne nazwy.

2. Sprawdź, czy MySQL w ogóle żyje

Na hostingach współdzielonych nie masz dostępu do restartu bazy — ale masz dostęp do telefonu i czatu z helpdeskiem. Jeżeli skrypt testowy PHP z punktu wyżej zwraca „Can’t connect to MySQL server”, zadzwoń lub napisz do hostingu. Pytanie, które zadajesz, brzmi: „Czy serwer MySQL dla mojej usługi jest aktywny i czy nie ma aktualnie przerwy technicznej?”

Jeżeli prowadzisz stronę na VPS lub serwerze dedykowanym, zaloguj się przez SSH i sprawdź status:

sudo systemctl status mysql
sudo systemctl restart mysql

Na niektórych systemach usługa nazywa się mysqld lub mariadb. Po restarcie odśwież stronę — w 60% przypadków to rozwiązuje sprawę na co najmniej kilka godzin (a to daje Ci czas na znalezienie prawdziwej przyczyny).

3. Napraw uszkodzoną bazę danych (WP_ALLOW_REPAIR)

Jeżeli WordPress podpowiada komunikat „One or more database tables are unavailable”, aktywuj wbudowany mechanizm naprawy. Dodaj do wp-config.php ten wiersz (najlepiej na samym końcu, przed linią /* That's all, stop editing! */):

define( 'WP_ALLOW_REPAIR', true );

Następnie wejdź pod adres:

https://twojadomena.pl/wp-admin/maint/repair.php

Zobaczysz dwie opcje: „Repair Database” oraz „Repair and Optimize Database”. Wybierz drugą — różnica w czasie jest minimalna, a optymalizacja skróci czas ładowania strony po naprawie.

Ważne: po zakończeniu naprawy natychmiast usuń linijkę WP_ALLOW_REPAIR z wp-config.php. Dopóki tam jest, strona repair.php jest publicznie dostępna bez logowania — to poważna luka.

4. Sprawdź uprawnienia użytkownika MySQL

Po migracji zdarza się, że nowy użytkownik bazy nie ma pełnych uprawnień do starej bazy. W phpMyAdmin przejdź do zakładki „Uprawnienia” i upewnij się, że Twój użytkownik ma zaznaczone co najmniej: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP. W panelach typu DirectAdmin czy cPanel jest osobna sekcja „Przypisz użytkownika do bazy” — tam po prostu klikasz „Wszystkie uprawnienia”.

5. Sprawdź, czy nie zabrakło miejsca na dysku

Na VPS zaloguj się przez SSH i wpisz:

df -h

Jeżeli partycja, na której leży baza (najczęściej / albo /var), ma 100% wypełnienia — MySQL nie może zapisać nawet tymczasowego pliku i odmawia połączeń. Szybkie rozwiązanie: wyczyść stare logi (/var/log), kopie bazy, niezaktualizowane pakiety. Na hostingu współdzielonym — sprawdź zużycie przestrzeni w panelu i poproś hosting o rozszerzenie lub wyczyść nieużywane kopie zapasowe.

6. Wyłącz wtyczki przez FTP

Jeżeli błąd pojawił się tuż po instalacji nowej wtyczki lub aktualizacji, nie masz dostępu do panelu, więc standardowa deaktywacja odpada. Zamiast tego:

1. Zaloguj się przez FTP.
2. Przejdź do wp-content/.
3. Zmień nazwę folderu plugins na plugins-off.
4. Odśwież stronę.

Jeżeli strona wstaje — wiesz, że winowajcą jest wtyczka. Przywróć folder do nazwy plugins, a następnie wchodź do niego i zmieniaj nazwy poszczególnych katalogów wtyczek po jednej, aż trafisz na tę, która powoduje problem.

7. Przywróć ostatnią działającą kopię zapasową

Jeżeli wszystkie powyższe kroki nie pomogły, a strona jest Twoim źródłem utrzymania — nie trać czasu. Przywróć backup z momentu, w którym strona jeszcze działała. Większość hostingów (zwłaszcza tych z LSCache lub LiteSpeed) oferuje punktowe przywracanie w panelu klienta — szukaj sekcji „Backup”, „Kopie zapasowe” albo „R1Soft”. Czas przywracania to zwykle 5–15 minut.

Jak zapobiec błędowi w przyszłości?

Naprawienie „Error establishing a database connection” raz to jedno — ale chcesz, żeby się nie powtórzyło. Kilka nawyków, które znacząco zmniejszają ryzyko:

• Codzienne automatyczne backupy — najlepiej zewnętrzne (np. na Google Drive, nie tylko na tym samym serwerze, na którym stoi strona).
• Monitoring uptime z alertami SMS — narzędzia typu UptimeRobot czy Pingdom powiadomią Cię o awarii w ciągu minuty, a nie kiedy klient zadzwoni po trzech godzinach.
• Cache pełnych stron — jeżeli masz włączony LiteSpeed Cache lub podobne rozwiązanie, odwiedzający mogą zobaczyć stronę nawet wtedy, gdy baza nie działa.
• Monitoring zasobów MySQL — okresowy podgląd liczby zapytań i maksymalnej liczby połączeń pozwala wyłapać przeciążenie, zanim stanie się awarią.
• Regularna optymalizacja bazy (np. przez wtyczkę WP-Optimize raz w miesiącu) — usuwa niepotrzebne rewizje, spam, transjenty.

Najczęściej zadawane pytania

Czy przez ten błąd mogę stracić dane?

W zdecydowanej większości przypadków — nie. Błąd dotyczy połączenia, a nie zawartości bazy. Dane wciąż siedzą bezpiecznie na serwerze MySQL, po prostu WordPress ich chwilowo nie widzi. Wyjątkiem jest sytuacja, w której doszło do fizycznego uszkodzenia dysku albo nadpisania bazy — wtedy ratunkiem jest backup.

Jak długo WordPress pokazuje ten błąd?

Dopóki nie zostanie naprawiony. WordPress nie ma mechanizmu samonaprawy — strona będzie wyświetlać komunikat, dopóki ktoś nie usunie źródłowej przyczyny.

Czy błąd „Error establishing a database connection” wpływa na SEO?

Tak, i bardziej niż mogłoby się wydawać. Google traktuje takie strony jak 5xx Internal Server Error — jeżeli Googlebot trafi na stronę podczas awarii, spróbuje za jakiś czas ponownie. Krótka awaria (do kilku godzin) nie zrobi znaczącej krzywdy. Ale awaria trwająca dzień lub dłużej może doprowadzić do chwilowego deindeksowania części podstron. Dlatego tak ważny jest monitoring uptime i szybka reakcja.

Kiedy dzwonić do hostingu, a kiedy próbować samodzielnie?

Jeżeli strona była na poniedziałek, a błąd pojawił się nagle bez żadnych zmian z Twojej strony — dzwoń od razu. Najprawdopodobniej problem jest po stronie hostingu (MySQL padł, za dużo połączeń, awaria dysku). Jeżeli błąd pojawił się po Twoich zmianach (migracja, aktualizacja, edycja wp-config.php) — najpierw przejdź przez kroki 1–6 z tego poradnika, a dopiero potem angażuj support.

Podsumowanie

„Error establishing a database connection” wygląda strasznie, ale w 9 na 10 przypadków da się go zdjąć w kilka minut. Startuj zawsze od wp-config.php i testu połączenia przez prosty skrypt PHP — to dwie rzeczy, które wykluczają połowę przyczyn. Jeżeli to nie pomaga, weź pod lupę bazę (WP_ALLOW_REPAIR), potem wtyczki, a w ostateczności przywróć backup.

A żeby nie wracać do tego poradnika po raz drugi: zadbaj o backupy, monitoring uptime i cache. Kilka minut konfiguracji oszczędza dziesiątki godzin panicznego debugowania o 2:00 w nocy.

Jeżeli po awarii zauważyłeś, że po powrocie strony pojawia się też biała strona w WordPress (WSOD) — to zupełnie inny błąd, z inną diagnostyką. Masz pełny poradnik pod linkiem.