Wchodzisz na stronę i zamiast WordPressa widzisz tylko „Error establishing a database connection”? To jeden z tych komunikatów, które wyglądają poważnie, ale jednocześnie dość dobrze zawężają obszar poszukiwań. WordPress nie może prawidłowo połączyć się z bazą danych.
Strona WordPress składa się w dużym uproszczeniu z dwóch części: plików znajdujących się na serwerze oraz bazy MySQL/MariaDB, w której zapisane są m.in. wpisy, ustawienia, użytkownicy, konfiguracja wtyczek i dane WooCommerce.
Jeżeli PHP ma dostęp do plików WordPressa, ale nie potrafi odczytać bazy, strona nie ma z czego zbudować swojej zawartości. Zamiast losowo wyłączać wtyczki, zaczynam więc od sprawdzenia połączenia WordPress → serwer bazy danych.
Najpierw sprawdzam DB_NAME, DB_USER, DB_PASSWORD i DB_HOST w wp-config.php.
Poprawne dane nie pomogą, jeśli MySQL/MariaDB jest niedostępny lub przeciążony.
Po migracji częstym problemem są stare dane dostępowe do poprzedniej bazy.
DB_HOST nie zawsze ma wartość localhost.
WP_ALLOW_REPAIR służy do naprawy tabel, a nie błędnego hasła czy niedziałającego MySQL.
Przy błędzie pojawiającym się tylko okresowo sprawdzam obciążenie i limity serwera.
Co oznacza „Error establishing a database connection”?
Podczas każdego zwykłego wejścia na stronę WordPress musi pobrać wiele informacji z bazy danych.
Proces wygląda mniej więcej tak:
Użytkownik otwiera stronę.
PHP uruchamia aplikację i odczytuje wp-config.php.
WordPress próbuje połączyć się z MySQL lub MariaDB.
Dane z bazy są wykorzystywane do wygenerowania widoku.
Jeśli trzeci etap nie powiedzie się, WordPress nie ma dostępu do informacji potrzebnych do wygenerowania strony i wyświetla komunikat o błędzie połączenia.
Najczęstsze przyczyny błędu połączenia z bazą WordPress
Nieprawidłowa nazwa bazy, login, hasło albo adres serwera MySQL.
Usługa bazy jest zatrzymana, przeciążona albo chwilowo niedostępna.
Baza lub konkretne tabele mogą być uszkodzone albo niedostępne.
Przy działającym wcześniej WordPressie częstym scenariuszem jest również awaria hostingu, zmiana hasła użytkownika MySQL albo przeciążenie serwera bazy.
Przy świeżej migracji w pierwszej kolejności podejrzewam natomiast konfigurację dostępu.
1. Sprawdź dane bazy w wp-config.php
Plik:
wp-config.phpznajduje się zazwyczaj w głównym katalogu instalacji WordPressa.
Interesują mnie przede wszystkim cztery wartości:
define( 'DB_NAME', 'nazwa_bazy' );
define( 'DB_USER', 'uzytkownik_bazy' );
define( 'DB_PASSWORD', 'haslo_bazy' );
define( 'DB_HOST', 'localhost' );Każda z nich musi odpowiadać rzeczywistym danym skonfigurowanym na hostingu.
Plik zawiera dane dostępowe do bazy oraz inne informacje bezpieczeństwa WordPressa. Jeśli prosisz kogoś o pomoc, nie wklejaj publicznie całego pliku ani prawdziwego hasła.
2. Sprawdź DB_NAME – nazwę bazy danych
WordPress musi wiedzieć, z którą bazą ma się połączyć.
W panelu hostingu mogę mieć np.:
moja_firma_wp328a w wp-config.php:
define( 'DB_NAME', 'moja_firma_wp327' );Jedna różniąca się cyfra wystarczy, żeby połączenie nie działało prawidłowo.
To szczególnie częsty błąd po:
- migracji pomiędzy hostingami,
- przywracaniu kopii zapasowej,
- tworzeniu stagingu,
- ręcznym kopiowaniu WordPressa,
- zmianie nazwy bazy w panelu serwera.
3. Sprawdź DB_USER i DB_PASSWORD
Sama baza może istnieć i działać prawidłowo, ale WordPress musi posiadać użytkownika, który ma prawo się z nią połączyć.
DB_USER
+
DB_PASSWORD
+
uprawnienia do właściwej bazyCzęsty przypadek wygląda tak:
hasło użytkownika MySQL zostało zmienione
↓
wp-config.php nadal zawiera stare hasło
↓
WordPress nie może się uwierzytelnić
↓
Error establishing a database connection
Jeżeli nie znam aktualnego hasła, zamiast zgadywać
mogę ustawić nowe w panelu hostingu i wpisać tę samą
wartość do DB_PASSWORD.
Użytkownik musi mieć dostęp do właściwej bazy
Na części hostingów samo utworzenie użytkownika MySQL nie oznacza jeszcze automatycznego przypisania go do bazy.
Sprawdzam więc:
- czy użytkownik istnieje,
- czy jest przypisany do konkretnej bazy,
- czy posiada wymagane uprawnienia,
- czy jego hasło odpowiada wartości w wp-config.php.
4. DB_HOST nie zawsze oznacza localhost
Bardzo częsty poradnikowy skrót wygląda tak:
define( 'DB_HOST', 'localhost' );I rzeczywiście na wielu serwerach jest to poprawna wartość. Nie jest jednak uniwersalna.
Hosting może wymagać np.:
mysql123.hosting.example
127.0.0.1
127.0.0.1:3307
mysql123.hosting.example:3307Możliwa jest również konfiguracja korzystająca z konkretnego socketu MySQL.
Dlatego DB_HOST zawsze porównuję z informacją podaną przez dostawcę hostingu.
Obie wartości mogą zachowywać się inaczej zależnie od konfiguracji serwera. Wpisuję dokładnie host, port lub socket wymagany przez dane środowisko.
5. Sprawdź, czy serwer MySQL w ogóle działa
Jeżeli wszystkie dane są poprawne, kolejnym krokiem jest sam serwer bazy.
Mogę mieć idealny wp-config.php, ale jeśli MySQL:
- jest zatrzymany,
- uległ awarii,
- jest restartowany,
- osiągnął limit połączeń,
- nie odpowiada z powodu przeciążenia,
- nie ma miejsca na dysku,
- został zablokowany przez problem infrastrukturalny,
WordPress nadal nie będzie w stanie się połączyć.
Na hostingu współdzielonym często najszybszym testem jest sprawdzenie panelu usług albo zgłoszenie do supportu z pytaniem, czy baza wskazana w wp-config.php odpowiada i czy nie występują problemy po stronie MySQL/MariaDB.
6. Błąd pojawia się tylko czasami? Podejrzewam przeciążenie
Inaczej diagnozuję stronę, która jest całkowicie niedostępna przez wiele godzin, a inaczej WordPress, który:
09:00 → działa
09:05 → database connection error
09:06 → działa
09:20 → database connection error
09:21 → działaPrzy takim zachowaniu sprawdzam szczególnie:
- liczbę jednoczesnych połączeń MySQL,
- obciążenie CPU i RAM,
- wolne zapytania SQL,
- ruch botów,
- WP-Cron,
- Action Scheduler,
- importy produktów,
- backup wykonywany w tle,
- ciężkie procesy WooCommerce.
Wtedy dane dostępowe mogą być całkowicie poprawne. WordPress traci połączenie dlatego, że infrastruktura nie radzi sobie pod obciążeniem.
Dlaczego większy ruch może ujawnić problem?
Jedno wejście użytkownika może uruchamiać wiele zapytań. Sklep WooCommerce wykonuje zwykle jeszcze więcej pracy niż prosta strona wizytówkowa.
więcej użytkowników
+
więcej zapytań
+
ciężkie wtyczki
+
boty
↓
więcej połączeń z bazą
↓
serwer osiąga limit
↓
część żądań nie może połączyć się z MySQLW takim przypadku trwałe rozwiązanie polega na optymalizacji lub zwiększeniu odpowiednich zasobów, a nie ciągłym restartowaniu strony.
7. Error establishing a database connection po migracji WordPressa
To jeden z najczęstszych momentów wystąpienia błędu.
Kopiuję pliki na nowy serwer, importuję bazę, zmieniam DNS i widzę błąd połączenia.
Sprawdzam wtedy:
- czy baza została rzeczywiście utworzona,
- czy import zakończył się bez błędu,
- czy wp-config.php wskazuje nową bazę,
- czy użytkownik MySQL istnieje na nowym serwerze,
- czy użytkownik ma prawa do bazy,
- czy DB_HOST odpowiada nowemu hostingowi.
Pliki WordPressa mogą zostać przeniesione idealnie, ale dane do bazy z poprzedniego hostingu nie będą działały na nowym środowisku.
8. Problem na localhost? Sprawdź, czy MySQL został uruchomiony
Przy środowisku lokalnym błąd często ma bardzo prostą przyczynę.
Apache lub Nginx działa, PHP również, ale baza MySQL/MariaDB nie została uruchomiona.
Dotyczy to m.in. środowisk typu:
- XAMPP,
- WAMP,
- MAMP,
- Docker,
- własne lokalne środowisko developerskie.
Sprawdzam więc nie tylko konfigurację WordPressa, ale status samej usługi bazy.
9. Masz SSH? Sprawdź połączenie przez WP-CLI
Jeśli hosting udostępnia WP-CLI, bardzo wygodnym testem jest:
wp db checkPolecenie korzysta z danych zapisanych w wp-config.php i sprawdza stan bazy.
Przy poprawnym działaniu mogę otrzymać:
Success: Database checked.Jeśli dane dostępowe albo serwer bazy są nieprawidłowe, polecenie pomoże potwierdzić, że problem rzeczywiście występuje na połączeniu z bazą, a nie tylko na frontendzie strony.
10. Kiedy użyć WP_ALLOW_REPAIR?
Jeżeli połączenie z serwerem działa, ale WordPress zgłasza problem z uszkodzonymi tabelami, można skorzystać z wbudowanego mechanizmu naprawy.
W wp-config.php tymczasowo dodaję:
define( 'WP_ALLOW_REPAIR', true );Następnie otwieram:
https://twojadomena.pl/wp-admin/maint/repair.phpWordPress udostępni możliwość sprawdzenia i naprawy tabel bazy.
Strona naprawy została zaprojektowana tak, aby działać również wtedy, gdy użytkownik nie może zalogować się do WordPressa. Z tego powodu podczas aktywacji nie wymaga normalnego logowania administratora.
WP_ALLOW_REPAIR nie naprawi każdego błędu
To bardzo ważne.
WordPress nie ma prawidłowych danych, żeby połączyć się z bazą.
Jeżeli połączenie działa, mechanizm może spróbować naprawić obsługiwane problemy tabel.
Podobnie mechanizm naprawy nie uruchomi za Ciebie wyłączonego serwera MySQL.
11. Naprawa bazy przez WP-CLI
Na serwerze z odpowiednim dostępem mogę również użyć:
wp db checka jeżeli diagnoza potwierdzi problem wymagający naprawy:
wp db repairNie uruchamiam jednak polecenia naprawczego rutynowo przy każdym błędzie połączenia.
Najpierw ustalam, czy problem dotyczy:
połączenia
czy
stanu samych tabel12. Czy baza jest widoczna w phpMyAdmin?
Jeżeli hosting udostępnia phpMyAdmin, sprawdzam, czy jestem w stanie:
- zalogować się do serwera MySQL,
- zobaczyć właściwą bazę,
- otworzyć listę tabel,
- zobaczyć np. tabelę options, posts i users.
Jeżeli phpMyAdmin również nie może połączyć się z serwerem, mocno wskazuje to na problem szerszy niż WordPress.
Jeśli phpMyAdmin działa, ale WordPress nie, wracam do danych zapisanych w wp-config.php, hosta oraz uprawnień użytkownika.
13. Co jeśli tabela bazy jest uszkodzona?
W logach albo narzędziach bazodanowych mogę spotkać komunikaty wskazujące np. na uszkodzenie konkretnej tabeli.
Wtedy przed bardziej agresywnymi operacjami:
- robię kopię bazy, jeśli jest to możliwe,
- sprawdzam backup hostingu,
- identyfikuję konkretną uszkodzoną tabelę,
- próbuję standardowego mechanizmu repair,
- przy poważniejszym problemie kontaktuję się z hostingiem.
Jeżeli tabela została całkowicie utracona, „repair” nie zawsze będzie w stanie ją odtworzyć. W takim przypadku potrzebna może być kopia zapasowa.
14. Sprawdź limit bazy i wolne miejsce na serwerze
Problemy z bazą nie zawsze zaczynają się od WordPressa.
Na hostingu może skończyć się:
- miejsce na dysku,
- limit rozmiaru bazy,
- limit zasobów usługi,
- limit liczby połączeń.
Szczególnie przy WooCommerce baza może rosnąć znacznie szybciej ze względu na zamówienia, sesje, logi, Action Scheduler oraz dane rozszerzeń.
Jeśli WordPress regularnie przestaje działać przy dużym obciążeniu, samo poprawienie wp-config.php niczego nie rozwiąże.
15. Czy wtyczka może powodować Error establishing a database connection?
Błędne dane w wp-config.php i niedostępny MySQL są znacznie bardziej bezpośrednimi przyczynami.
Wtyczka może jednak pośrednio doprowadzić do problemu, jeżeli generuje bardzo ciężkie zapytania albo ogromną liczbę operacji bazodanowych.
ciężka wtyczka
+
duży ruch
↓
wysokie obciążenie bazy
↓
limit połączeń / przeciążenie
↓
część żądań traci dostęp do MySQLDlatego przy okresowych błędach pod obciążeniem analizuję również wtyczki i zapytania.
Jeśli natomiast błąd pojawia się stale od momentu migracji, wyłączanie wszystkich pluginów nie jest moim pierwszym krokiem.
16. Czy błędny prefiks tabel powoduje ten komunikat?
W wp-config.php znajduje się również:
$table_prefix = 'wp_';Wartość musi odpowiadać tabelom wykorzystywanym przez instalację.
Nie jest to jednak to samo co samo połączenie z serwerem MySQL. WordPress może poprawnie połączyć się z bazą, ale następnie nie znaleźć oczekiwanych tabel.
Dlatego przy klasycznym:
Error establishing a database connectionnajpierw skupiam się na DB_HOST, DB_NAME, DB_USER, DB_PASSWORD oraz dostępności serwera.
Najważniejsze pytanie: co wydarzyło się tuż przed awarią?
Historia problemu często pozwala skrócić diagnozę z godziny do kilku minut.
| Co wydarzyło się wcześniej? | Co sprawdzam w pierwszej kolejności? |
|---|---|
| Migracja strony | DB_NAME, DB_USER, DB_PASSWORD, DB_HOST. |
| Zmiana hasła MySQL | DB_PASSWORD w wp-config.php. |
| Zmiana hostingu | DB_HOST oraz przypisanie użytkownika do bazy. |
| Brak żadnych zmian | Status MySQL, awarię hostingu i zasoby. |
| Błąd tylko w godzinach szczytu | Limity połączeń, CPU, RAM i ciężkie zapytania. |
| Komunikaty o uszkodzonych tabelach | Backup, check/repair bazy i logi. |
Jak diagnozuję Error establishing a database connection krok po kroku?
Sprawdzam zakres awarii
Czy błąd występuje cały czas, tylko okresowo, na frontendzie i w panelu, czy zaczął się bezpośrednio po konkretnej zmianie?
Weryfikuję wp-config.php
Porównuję nazwę bazy, użytkownika, hasło i DB_HOST z aktualnymi danymi hostingu.
Sprawdzam dostępność MySQL
Kontroluję panel hostingu, phpMyAdmin, monitoring usługi lub pytam support o stan serwera.
Sprawdzam połączenie technicznie
Jeśli mam SSH, wykorzystuję WP-CLI i sprawdzam, czy te same dane pozwalają połączyć się z bazą.
Analizuję stan tabel
Dopiero gdy połączenie działa, sprawdzam, czy któraś tabela nie jest uszkodzona.
Sprawdzam obciążenie
Przy okresowym problemie analizuję zasoby, liczbę połączeń i procesy wykonujące ciężkie zapytania.
Naprawiam przyczynę i monitoruję stronę
Nie kończę na jednym poprawnym odświeżeniu. Sprawdzam, czy problem nie wraca przy większym ruchu albo podczas wykonywania zadań w tle.
Czego nie robię przy błędzie połączenia z bazą?
- Nie kasuję bazy i nie tworzę nowej bez diagnozy.
- Nie zmieniam DB_HOST na losową wartość z poradnika.
- Nie publikuję hasła MySQL ani całego wp-config.php.
- Nie uruchamiam naprawy tabel, jeśli problemem jest błędne hasło.
- Nie wyłączam wszystkich wtyczek jako pierwszego kroku po migracji.
- Nie nadpisuję działającej bazy pustą instalacją WordPressa.
- Nie wykonuję agresywnych operacji SQL bez backupu.
Kiedy potrzebne jest przywrócenie kopii zapasowej?
Sam komunikat o braku połączenia nie oznacza jeszcze, że dane zostały utracone.
Bardzo często baza istnieje i wystarczy przywrócić prawidłowe połączenie.
Backup zaczyna być szczególnie istotny, jeśli:
- brakuje wymaganych tabel,
- baza została przypadkowo nadpisana,
- część tabel jest poważnie uszkodzona,
- nieudana migracja pozostawiła niepełny import,
- doszło do usunięcia danych.
Przy sklepie WooCommerce przed przywróceniem starszej kopii sprawdzam dodatkowo, czy nie spowoduje to utraty nowych zamówień.
Awaria bazy to problem całej strony, nie tylko panelu WordPressa
Gdy baza przestaje odpowiadać, użytkownik nie zobaczy strony ofertowej, formularza kontaktowego ani sklepu.
W przypadku WooCommerce konsekwencja jest jeszcze większa: klient może zostać zatrzymany tuż przed zakupem.
Dlatego w ramach wsparcia technicznego WordPress i WooCommerce takie problemy diagnozuję od strony WordPressa, bazy danych oraz samego serwera, a nie tylko przez ponowne instalowanie wtyczek.
Jeśli awarie wracają, warto sprawdzić stan całego WordPressa
Jednorazowa awaria serwera MySQL może być przypadkiem. Jeżeli jednak witryna regularnie traci połączenie, ma stare PHP, dziesiątki nieużywanych wtyczek, ogromną bazę i stale dobija do limitów hostingu, problem jest szerszy.
W takim przypadku rozważam odświeżenie lub przebudowę istniejącej strony albo sklepu zamiast kolejnego doraźnego restartu.
Przy WooCommerce warto dodatkowo zweryfikować, czy obecna infrastruktura jest jeszcze adekwatna do liczby produktów, zamówień, integracji i ruchu.
Stabilny WordPress zaczyna się od poprawnej infrastruktury
Na stronynazlecenie.pl zajmuję się tworzeniem, rozwijaniem i naprawą stron oraz sklepów opartych o WordPress.
Przy nowym sklepie internetowym WooCommerce zwracam uwagę nie tylko na wygląd i checkout, ale również na hosting, PHP, bazę, cache i procesy, które później decydują o stabilności całego sklepu.
Moja checklista przy Error establishing a database connection
- Ustalam, kiedy dokładnie pojawił się błąd.
- Sprawdzam, czy problem jest stały czy okresowy.
- Weryfikuję DB_NAME.
- Weryfikuję DB_USER.
- Weryfikuję DB_PASSWORD.
- Sprawdzam DB_HOST oraz ewentualny port lub socket.
- Potwierdzam uprawnienia użytkownika MySQL.
- Sprawdzam działanie serwera MySQL/MariaDB.
- Kontroluję dostęp przez panel hostingu lub phpMyAdmin.
- Przy SSH wykorzystuję wp db check.
- Sprawdzam wolne miejsce i limity serwera.
- Przy błędzie okresowym analizuję obciążenie i liczbę połączeń.
- Dopiero po potwierdzeniu problemu tabel rozważam ich naprawę.
- Przed operacjami naprawczymi zabezpieczam kopię danych.
- Po naprawie monitoruję, czy problem nie pojawia się ponownie.
WordPress pokazuje Error establishing a database connection?
Mogę sprawdzić wp-config.php, dostęp do MySQL, stan bazy, logi, limity hostingu i obciążenie serwera. Ustalę, czy problemem są dane dostępowe, awaria bazy, uszkodzone tabele czy przeciążenie strony i naprawię właściwą przyczynę zamiast wykonywać przypadkowe zmiany.
Error establishing a database connection – najczęstsze pytania
Co oznacza Error establishing a database connection w WordPressie?
Komunikat oznacza, że WordPress nie może prawidłowo połączyć się z bazą danych. Sprawdzam przede wszystkim dane w wp-config.php, dostępność serwera MySQL oraz uprawnienia użytkownika bazy.
Jak naprawić Error establishing a database connection?
Najpierw porównuję DB_NAME, DB_USER, DB_PASSWORD i DB_HOST z danymi hostingu. Następnie sprawdzam, czy serwer MySQL działa i czy użytkownik ma dostęp do właściwej bazy. Dopiero później analizuję ewentualne uszkodzenie tabel.
Gdzie znajdują się dane do bazy WordPressa?
Podstawowe dane połączenia znajdują się zazwyczaj w pliku wp-config.php w głównym katalogu WordPressa. Są zapisane jako DB_NAME, DB_USER, DB_PASSWORD oraz DB_HOST.
Czy DB_HOST zawsze powinien mieć wartość localhost?
Nie. Wartość zależy od konfiguracji hostingu. Dostawca może wymagać osobnej nazwy serwera, adresu IP, portu albo socketu. Używam danych przekazanych dla konkretnego serwera.
Czy WP_ALLOW_REPAIR naprawi błąd połączenia z bazą?
Nie w każdym przypadku. Mechanizm służy przede wszystkim do naprawy problemów z tabelami. Nie naprawi błędnego hasła, złego DB_HOST ani wyłączonego serwera MySQL.
Jak uruchomić naprawę bazy WordPress?
Można tymczasowo dodać WP_ALLOW_REPAIR do wp-config.php i wejść na /wp-admin/maint/repair.php. Po zakończeniu należy usunąć tę stałą, ponieważ strona naprawy podczas jej aktywacji nie wymaga standardowego logowania.
Dlaczego błąd połączenia z bazą pojawia się tylko czasami?
Przy błędzie okresowym sprawdzam przeciążenie MySQL, limity liczby połączeń, CPU, pamięć, ciężkie zapytania, boty oraz zadania wykonywane w tle. Dane w wp-config.php mogą być wtedy całkowicie poprawne.
Czy błąd może pojawić się po migracji WordPressa?
Tak. Po migracji bardzo często przyczyną są stare dane bazy pozostawione w wp-config.php, niewłaściwy DB_HOST albo brak przypisania nowego użytkownika MySQL do zaimportowanej bazy.
Czy utraciłem stronę, jeśli pojawił się ten błąd?
Nie. Sam komunikat nie oznacza utraty danych. Bardzo często baza nadal istnieje, a WordPress po prostu nie może się z nią połączyć. Dopiero diagnostyka pozwala ustalić, czy doszło do rzeczywistego uszkodzenia danych.
