Błąd Unknown storage engine w MySQL lub MariaDB potrafi wyglądać groźnie, szczególnie wtedy, gdy strona WordPress, sklep internetowy albo panel aplikacji nagle przestaje działać. Najczęściej komunikat pojawia się przy próbie uruchomienia bazy, wykonania zapytania, importu kopii zapasowej albo po restarcie serwera. W praktyce oznacza, że silnik tabel, na przykład InnoDB, nie jest dostępny, nie może się załadować albo został uszkodzony.
Dobra wiadomość jest taka, że problem zwykle da się zawęzić do kilku przyczyn. Może chodzić o błędną konfigurację, uszkodzone pliki InnoDB, brak uprawnień, niedokończoną migrację, zbyt mało pamięci albo tabelę utworzoną w silniku, którego dana wersja MySQL już nie obsługuje. Poniżej znajdziesz praktyczny schemat diagnostyki i naprawy, który pomaga działać bez paniki i bez wykonywania ryzykownych operacji na ślepo.
Streszczenie artykułu:
- Unknown storage engine oznacza, że MySQL lub MariaDB nie może użyć wskazanego silnika tabel.
- Najczęściej problem dotyczy InnoDB, ponieważ jest to domyślny silnik większości współczesnych instalacji.
- Pierwszym krokiem powinna być analiza logów, a nie usuwanie plików bazy.
- Przy uszkodzeniu InnoDB warto użyć innodb_force_recovery, wykonać eksport danych i dopiero potem odbudować środowisko.
- W WordPress i Bitnami częstą przyczyną są uszkodzone logi InnoDB, błędne uprawnienia albo MariaDB, która nie startuje po restarcie instancji.
- Najbezpieczniejszą ochroną są regularne kopie zapasowe, testy migracji i monitorowanie logów bazy.
Ten artykuł jest przeznaczony dla administratorów stron, właścicieli serwisów WordPress, developerów, osób utrzymujących sklepy internetowe oraz wszystkich, którzy widzą komunikat ERROR 1286 Unknown storage engine InnoDB i chcą zrozumieć, co oznacza błąd, jak go sprawdzić oraz jak ograniczyć ryzyko utraty danych.
Co oznacza błąd Unknown storage engine?
Komunikat Unknown storage engine pojawia się wtedy, gdy MySQL lub MariaDB próbuje użyć silnika tabel, który nie jest dostępny w działającej instancji bazy danych. Silnik tabel odpowiada za sposób przechowywania, odczytu i zabezpieczania danych. Najczęściej spotykane silniki to InnoDB, MyISAM, MEMORY, ARCHIVE oraz CSV.
W praktyce błąd może wystąpić przy zwykłym zapytaniu, podczas tworzenia tabeli, przy imporcie pliku SQL albo w chwili startu bazy. Jeżeli aplikacja korzysta z tabel InnoDB, a InnoDB nie załaduje się poprawnie, strona może pokazać komunikat o braku połączenia z bazą danych, mimo że dane logowania są poprawne.
Typowe komunikaty wyglądają tak:
ERROR 1286 (42000): Unknown storage engine 'InnoDB'
ERROR 1286 (42000): Unknown storage engine 'MyISAM'
ERROR 1286 (42000): Unknown storage engine 'MEMORY'
ERROR 1286 (42000): Unknown storage engine 'ARCHIVE'
W logach serwera można też zobaczyć powiązane błędy:
Plugin 'InnoDB' init function returned error.
Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Unknown/unsupported storage engine: InnoDB.
InnoDB: Malformed log record.
InnoDB: The data file './ibdata1' must be writable.
Warto rozróżnić dwa scenariusze. Pierwszy dotyczy sytuacji, gdy silnik został wyłączony lub nie jest załadowany. Drugi jest poważniejszy, ponieważ oznacza, że silnik istnieje, ale nie może wystartować z powodu błędów w plikach, uprawnieniach albo konfiguracji.
Jak szybko zdiagnozować przyczynę błędu?
Diagnostykę zacznij od sprawdzenia, czy silnik jest widoczny dla bazy. Nie zakładaj od razu uszkodzenia danych, ponieważ czasem problem wynika z jednej linijki w konfiguracji albo z nieprawidłowych uprawnień po migracji katalogu danych. Najważniejsze jest ustalenie, czy MySQL widzi silnik, czy tylko nie potrafi go uruchomić.
W konsoli MySQL wykonaj:
SHOW ENGINES;
Następnie sprawdź konkretny silnik:
SELECT ENGINE, SUPPORT
FROM INFORMATION_SCHEMA.ENGINES
WHERE ENGINE = 'InnoDB';
Jeżeli InnoDB ma status DEFAULT albo YES, silnik jest dostępny. Jeżeli widzisz NO, DISABLED albo nie widzisz InnoDB w wynikach, trzeba sprawdzić konfigurację i logi startowe serwera.
Najważniejsze miejsca do sprawdzenia:
- status silników przez
SHOW ENGINES. - lista wtyczek przez
SHOW PLUGINS. - log błędów MySQL lub MariaDB.
- plik konfiguracyjny
my.cnf,mysqld.cnfalbo konfigurację Bitnami. - uprawnienia do katalogu danych.
- obecność plików
ibdata1,ib_logfile0iib_logfile1.
Lokalizację logu błędów możesz znaleźć poleceniem:
mysql -e "SHOW VARIABLES LIKE 'log_error'"
Popularne lokalizacje logów to:
/var/log/mysql/error.log
/var/log/mysqld.log
/var/lib/mysql/*.err
/opt/bitnami/mariadb/logs/mysqld.log
Jeżeli baza nie startuje, log jest najważniejszym źródłem informacji. Sam komunikat w aplikacji, na przykład w WordPress, często mówi tylko o problemie z połączeniem, ale nie wyjaśnia, dlaczego MariaDB albo MySQL odmawia uruchomienia.
Dlaczego InnoDB najczęściej powoduje ten problem?
InnoDB jest domyślnym i najczęściej używanym silnikiem w nowoczesnych instalacjach MySQL oraz MariaDB. Obsługuje transakcje, blokady na poziomie wierszy, klucze obce i mechanizmy odzyskiwania po awarii. Z tego powodu większość aplikacji, w tym WordPress, WooCommerce, Magento i wiele systemów autorskich, korzysta właśnie z InnoDB.
Problem polega na tym, że InnoDB potrzebuje poprawnie działających plików systemowych i dzienników transakcyjnych. Jeżeli serwer zostanie nagle wyłączony, instancja chmurowa zatrzymana w niewłaściwym momencie albo zabraknie miejsca na dysku, InnoDB może próbować wykonać odzyskiwanie po awarii. Gdy odzyskiwanie nie powiedzie się, cały silnik może nie zostać zarejestrowany.
Częsty scenariusz wygląda tak. Aplikacja działa poprawnie, następnie serwer zostaje zatrzymany na kilka dni albo restartuje się po awarii. Po ponownym uruchomieniu WordPress pokazuje błąd połączenia z bazą danych. W logu MariaDB pojawiają się wpisy o nieudanym odzyskiwaniu, uszkodzonym rekordzie logu, błędzie inicjalizacji InnoDB i komunikat Unknown or unsupported storage engine InnoDB.
Najczęstsze przyczyny problemów z InnoDB można podsumować w tabeli.
| Przyczyna | Objaw | Co sprawdzić |
|---|---|---|
| Wyłączony InnoDB | Silnik ma status disabled albo nie występuje w wynikach | my.cnf, mysqld.cnf, disabled_storage_engines |
| Uszkodzone logi InnoDB | Baza nie startuje po restarcie | ib_logfile0, ib_logfile1, log błędów |
| Błędne uprawnienia | Pliki nie są zapisywalne | właściciel katalogu danych, chmod, chown |
| Brak pamięci | InnoDB nie inicjuje bufora | innodb_buffer_pool_size, RAM serwera |
| Migracja katalogu danych | Brakuje plików InnoDB | kompletność danych po przeniesieniu |
Ta diagnoza jest ważna, ponieważ każda z przyczyn wymaga innej reakcji. Usunięcie plików bez kopii zapasowej może pogorszyć sytuację, dlatego najpierw należy potwierdzić źródło błędu.
Jak naprawić błąd, gdy InnoDB jest wyłączony?
Najprostszy przypadek występuje wtedy, gdy InnoDB został wyłączony w konfiguracji. Może to zdarzyć się po przeniesieniu konfiguracji ze starego serwera, po błędnej optymalizacji albo po użyciu gotowego obrazu systemu z nietypowymi ustawieniami. W takim przypadku dane nie muszą być uszkodzone, a naprawa polega na przywróceniu obsługi silnika.
Sprawdź pliki konfiguracyjne, na przykład:
/etc/mysql/mysql.conf.d/mysqld.cnf
/etc/my.cnf
/etc/mysql/my.cnf
/opt/bitnami/mariadb/conf/my.cnf
Szukaj ustawień podobnych do poniższych:
skip-innodb
innodb = OFF
disabled_storage_engines = "InnoDB"
Jeżeli je znajdziesz, usuń je albo zakomentuj. Następnie uruchom ponownie serwer bazy:
sudo systemctl restart mysql
W środowisku Bitnami polecenie może wyglądać tak:
sudo /opt/bitnami/ctlscript.sh restart mariadb
Po restarcie ponownie wykonaj:
SHOW ENGINES;
Jeżeli InnoDB wrócił jako DEFAULT albo YES, problem był konfiguracyjny. Warto wtedy sprawdzić, dlaczego ustawienie pojawiło się w pliku, aby nie wróciło po kolejnej aktualizacji, migracji albo wdrożeniu z automatycznego skryptu.
Jak odzyskać bazę przy uszkodzonym InnoDB?
Gdy log pokazuje błędy typu Malformed log record, Plugin InnoDB init function returned error albo Log scan aborted, problem może dotyczyć uszkodzonych dzienników lub przestrzeni tabel InnoDB. W takiej sytuacji najważniejsza zasada brzmi, najpierw zabezpiecz dane, potem naprawiaj środowisko.
Pierwszym krokiem jest wykonanie kopii katalogu danych, nawet jeżeli baza nie startuje. Kopia plikowa nie zawsze wystarczy do pełnego odzyskania, ale daje możliwość powrotu do punktu wyjścia, gdy kolejna operacja się nie powiedzie.
Przykład:
sudo systemctl stop mysql
sudo cp -a /var/lib/mysql /var/lib/mysql_backup_before_recovery
W Bitnami katalog może znajdować się tutaj:
sudo cp -a /opt/bitnami/mariadb/data /opt/bitnami/mariadb/data_backup_before_recovery
Następnie można użyć trybu awaryjnego InnoDB. W pliku konfiguracyjnym w sekcji serwera dodaj:
[mysqld]
innodb_force_recovery = 1
Jeżeli baza nie startuje, można zwiększać poziom stopniowo od 1 do 6. Nie zaczynaj od najwyższego poziomu, ponieważ wyższe wartości są bardziej ryzykowne i służą głównie do odczytu oraz eksportu danych.
| Poziom | Znaczenie praktyczne |
|---|---|
| 1 | Pomija część uszkodzonych stron |
| 2 | Pomija operacje tła |
| 3 | Pomija wycofywanie transakcji |
| 4 | Pomija scalanie insert buffer |
| 5 | Pomija logi undo |
| 6 | Pomija odtwarzanie redo log |
Po uruchomieniu bazy w trybie awaryjnym wykonaj eksport:
mysqldump --all-databases --routines --triggers > backup.sql
Dopiero po skutecznym eksporcie można odbudować bazę, usunąć tryb odzyskiwania z konfiguracji, utworzyć czyste środowisko i zaimportować dane. Jeżeli problem dotyczy wyłącznie logów InnoDB, czasem pomaga zmiana nazwy uszkodzonego pliku dziennika, na przykład ib_logfile0, ale taką operację wykonuj wyłącznie po kopii i po analizie logów.
Co zrobić, gdy problem występuje w WordPress lub Bitnami?
W WordPress komunikat widoczny dla użytkownika często brzmi po prostu, błąd łączenia się z bazą danych. To nie znaczy automatycznie, że hasło w wp-config.php jest złe. Jeżeli MariaDB nie startuje, WordPress nie ma z czym się połączyć, nawet jeśli konfiguracja aplikacji jest poprawna.
W środowisku Bitnami diagnostykę warto zacząć od restartu MariaDB i sprawdzenia logów:
sudo /opt/bitnami/ctlscript.sh restart mariadb
sudo tail -n 50 /opt/bitnami/mariadb/logs/mysqld.log
Jeżeli widzisz wpisy o InnoDB, uszkodzonym logu albo nieudanej rejestracji silnika, problem leży po stronie bazy. Jeżeli widzisz błędy uprawnień, na przykład brak możliwości utworzenia pliku logu albo brak zapisu do ibdata1, sprawdź właściciela i prawa do katalogu danych.
Przy ręcznym uruchamianiu mysqld pamiętaj o uprawnieniach. Błędy typu Permission denied oraz One can only use the user switch if running as root wskazują, że polecenie zostało uruchomione w niewłaściwym kontekście. W wielu instalacjach potrzebne jest sudo, ale sam fakt uruchomienia procesu nie oznacza jeszcze, że aplikacja odzyska dostęp.
W przypadku WordPress trzeba też pamiętać o wtyczkach, motywach i tłumaczeniach. Czasem komunikat związany z InnoDB pojawia się przy konkretnym wpisie w tabeli opcji, tłumaczeniach stringów albo danych motywu. Jeżeli baza działa, a problem występuje punktowo, warto sprawdzić ostatnie zmiany w motywie, wtyczkach oraz tabelach opcji.
Jak sprawdzić tabele i silniki po uruchomieniu bazy?
Gdy baza zacznie działać, sprawdź, jakie silniki są używane przez tabele. To ważne szczególnie po migracji, imporcie starego dumpa albo aktualizacji MySQL. Czasem część tabel korzysta z silnika, który nie jest dostępny w nowym środowisku, co powoduje błędy dopiero przy próbie odczytu konkretnej tabeli.
Użyj zapytania:
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
Jeżeli chcesz znaleźć tabele inne niż InnoDB:
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE != 'InnoDB'
AND TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys');
Konwersja tabeli do InnoDB może wyglądać tak:
ALTER TABLE nazwa_tabeli ENGINE = InnoDB;
Nie wykonuj masowej konwersji bez kopii zapasowej. Przy dużych tabelach operacja może potrwać, zablokować zasoby i zwiększyć użycie dysku. Najpierw przetestuj ją na kopii środowiska, szczególnie jeżeli serwis działa produkcyjnie.
Przy imporcie starego pliku SQL zwróć uwagę na fragmenty typu:
ENGINE=MyISAM
ENGINE=ARCHIVE
ENGINE=MEMORY
Jeżeli nowa instalacja nie obsługuje wskazanego silnika, import może się zatrzymać. Wtedy można dostosować dump, ale trzeba rozumieć konsekwencje, ponieważ nie każdy silnik ma takie same cechy jak InnoDB.
Jak zapobiegać błędom Unknown storage engine?
Najlepsza naprawa to taka, której nie trzeba wykonywać pod presją niedziałającej strony. Błędy silników baz danych często pojawiają się po restartach, awariach, migracjach, aktualizacjach i zmianach uprawnień. Dlatego profilaktyka powinna obejmować zarówno kopie zapasowe, jak i kontrolę konfiguracji.
Dobre praktyki:
- wykonuj regularne kopie
mysqldumporaz kopie plikowe zgodne z procedurą dla używanego środowiska. - testuj aktualizacje MySQL i MariaDB na kopii serwera.
- monitoruj log błędów bazy, miejsce na dysku i zużycie pamięci.
- nie wyłączaj InnoDB, jeżeli aplikacja korzysta z WordPress, WooCommerce lub nowoczesnych frameworków.
- po migracji sprawdzaj właściciela i uprawnienia katalogu danych.
- przed importem starego dumpa sprawdzaj użyte silniki tabel.
- trzymaj procedurę odzyskiwania w dokumentacji technicznej projektu.
W konfiguracji warto jawnie ustawić domyślny silnik:
[mysqld]
default_storage_engine = InnoDB
Warto też regularnie sprawdzać stan InnoDB:
SHOW ENGINE INNODB STATUS\G
Jeżeli baza działa w chmurze, unikaj gwałtownego zatrzymywania instancji podczas intensywnych zapisów. Dbaj też o wolne miejsce na dysku, ponieważ pełny dysk może prowadzić do uszkodzeń, nieudanych zapisów i problemów z odtwarzaniem po awarii.
Podsumowanie
Błąd Unknown storage engine nie zawsze oznacza utratę danych, ale zawsze wymaga spokojnej diagnostyki. Najpierw sprawdź dostępne silniki przez SHOW ENGINES, potem przeanalizuj log błędów i konfigurację. Jeżeli problem dotyczy InnoDB, zwróć szczególną uwagę na komunikaty o uszkodzonych logach, błędach inicjalizacji, uprawnieniach oraz plikach ibdata1 i ib_logfile.
Najbezpieczniejsza kolejność działania to kopia danych, analiza logów, próba uruchomienia w trybie awaryjnym, eksport przez mysqldump i odbudowa środowiska. Dopiero po zabezpieczeniu danych warto rozważać operacje na plikach InnoDB. W WordPress i Bitnami nie sugeruj się wyłącznie komunikatem aplikacji, ponieważ prawdziwa przyczyna zwykle znajduje się w logach MariaDB lub MySQL. Regularne kopie zapasowe, testy migracji i monitoring pozwalają ograniczyć ryzyko, że pojedynczy restart serwera zamieni się w poważną awarię.
FAQ – Najczęściej zadawane pytania
Co oznacza ERROR 1286 Unknown storage engine InnoDB?
Oznacza, że MySQL lub MariaDB nie może użyć silnika InnoDB. Przyczyną może być wyłączenie silnika w konfiguracji, uszkodzenie plików InnoDB, błędne uprawnienia, problem po migracji albo nieudane odzyskiwanie po awarii.
Czy błąd Unknown storage engine oznacza utratę danych?
Nie zawsze. Dane mogą nadal znajdować się w katalogu bazy, ale silnik nie potrafi ich odczytać. Przed każdą naprawą wykonaj kopię plików i dopiero potem próbuj uruchomić bazę w trybie odzyskiwania.
Jak sprawdzić, czy InnoDB działa?
Wykonaj zapytanie SHOW ENGINES; i sprawdź status InnoDB. Możesz też użyć zapytania do INFORMATION_SCHEMA.ENGINES, aby zobaczyć, czy silnik ma status YES, DEFAULT, NO albo DISABLED.
Czy mogę usunąć pliki ib_logfile0 i ib_logfile1?
Nie rób tego bez kopii zapasowej i analizy logów. W niektórych przypadkach zmiana nazwy uszkodzonego pliku logu pomaga, ale przy nieprawidłowym użyciu może pogorszyć sytuację. Najpierw zabezpiecz katalog danych.
Co zrobić, gdy WordPress pokazuje błąd połączenia z bazą?
Sprawdź, czy MySQL lub MariaDB działa. Jeżeli usługa nie startuje, przejrzyj log błędów bazy. W WordPress komunikat o połączeniu często jest skutkiem awarii MariaDB, a nie błędnego hasła w wp-config.php.
Gdzie dodać innodb_force_recovery?
Dodaj innodb_force_recovery = 1 w sekcji [mysqld] pliku konfiguracyjnego bazy. Jeżeli dodasz wpis w złej sekcji, serwer może go zignorować. Po eksporcie danych usuń ten parametr z konfiguracji.
Czy MyISAM można zamienić na InnoDB?
Tak, zwykle można użyć ALTER TABLE nazwa_tabeli ENGINE = InnoDB;. Przed konwersją wykonaj kopię zapasową i sprawdź aplikację na środowisku testowym, ponieważ silniki różnią się funkcjami oraz zachowaniem.