Przewodnik rozwiązywania problemów z pakietami ServBay MariaDB/MySQL
Wprowadzenie
MariaDB i MySQL to wiodące, otwarte systemy zarządzania relacyjnymi bazami danych, szeroko stosowane w aplikacjach webowych i biznesowych. ServBay integruje w środowisku macOS i Windows różne wersje pakietów MariaDB/MySQL, zapewniając deweloperom wygodne oraz wydajne środowisko lokalnych baz danych. Mimo wysokiej stabilności, w pracy ze środowiskiem mogą pojawić się problemy dotyczące uruchomienia, połączenia czy spadków wydajności.
Ten przewodnik ma na celu pomoc użytkownikom ServBay w diagnozie i naprawie typowych problemów z pakietami MariaDB/MySQL. Obejmuje najczęściej spotykane błędy, kroki diagnostyczne i konkretne rozwiązania, ze wskazaniem ścieżek i poleceń specyficznych dla środowiska ServBay.
Ważne wskazówki:
- Przed wykonaniem jakiejkolwiek czynności mogącej wpłynąć na dane lub konfigurację, zawsze wykonaj kopię zapasową swojej bazy danych! ServBay posiada wbudowaną funkcję backupu — korzystaj z niej regularnie.
- Przykłady poleceń i ścieżek zawierają konkretne wersje (np.
11.3
lub11.5
). Zastąp je rzeczywistymi numerami wersji używanymi w Twoim środowisku ServBay. Możesz sprawdzić aktywne wersje w interfejsie ServBay. - W poleceniach takich jak
<username>
,<database>
,<your_backup.sql>
są to przykładowe miejsca na wpisanie faktycznych nazw użytkownika, bazy czy pliku backupu. - Przewodnik uwzględnia systemy macOS i Windows, a przykłady ścieżek czy poleceń są dostosowane odpowiednio do danego systemu.
Ogólne kroki diagnostyczne
Zanim przystąpisz do szczegółowego rozwiązywania problemów, wykonaj podstawowe sprawdzenia:
Sprawdź status pakietu ServBay: Otwórz aplikację ServBay i upewnij się, że wybrana wersja MariaDB/MySQL jest aktywna i oznaczona jako "uruchomiona". Możesz też skorzystać z terminala:
bashservbayctl status mariadb <version> # Przykład sprawdzenia statusu MariaDB 11.3: servbayctl status mariadb 11.3
1
2
3Przejrzyj logi aplikacji ServBay: Błędy mogą być zapisane w sekcji logów interfejsu ServBay lub w głównym pliku logów aplikacji.
Sprawdź log błędów MariaDB/MySQL: Kluczowy krok w przypadku awarii startu czy błędów runtime. Lokalizacja pliku logu:
macOS:
bash/Applications/ServBay/logs/mariadb/<version>/<version>.err # Przykład: wyświetlenie ostatnich 50 linii błędów MariaDB 11.3: tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err
1
2
3Windows:
cmdC:\ServBay\logs\mariadb\<version>\<version>.err # Przykład: ostatnie 50 linii logu błędów MariaDB 11.3: powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"
1
2
3Przeczytaj dokładnie końcowe komunikaty logów — często wskazują przyczynę problemu.
Typowe problemy i rozwiązania
1. Błąd połączenia: SQLSTATE[HY000] [2002] No such file or directory
Taki komunikat zwykle oznacza, że klient nie może połączyć się z serwerem MariaDB/MySQL przez plik Unix socket. Na macOS socket jest wykorzystywany do lokalnej komunikacji między procesami, a jego użycie jest szybsze niż TCP/IP. Jeśli aplikacja lub CLI nie znajduje pliku socket na spodziewanej ścieżce, pojawi się ten błąd.
Możliwe przyczyny i rozwiązania:
- Pakiet MariaDB/MySQL nie jest uruchomiony:
- Sprawdź status przez ServBay GUI lub polecenie
servbayctl status mariadb <version>
. - Jeśli nie działa, uruchom go:
servbayctl start mariadb <version>
. Przy awarii sprawdź log błędów (.err
).
- Sprawdź status przez ServBay GUI lub polecenie
- Nieprawidłowa ścieżka pliku socket (dotyczy tylko macOS/Linux):
- Używana przez klienta ścieżka socket różni się od ustawionej w serwerze (
my.cnf
). - macOS: Sprawdź parametr
socket
w pliku/Applications/ServBay/etc/mariadb/<version>/my.cnf
. - Windows: Ten system nie korzysta z Unix socket — tu działa TCP/IP lub named pipes.
- macOS: Upewnij się, że aplikacja lub klient używa właściwej ścieżki do socketu, albo domyślnej ścieżki ServBay. Najczęściej jest to
/Applications/ServBay/tmp/mysql.sock
albo/tmp/mysql.sock
.
- Używana przez klienta ścieżka socket różni się od ustawionej w serwerze (
- Błąd ustawień domyślnych ServBay:
- W ustawieniach ServBay (
Ustawienia
→Domyślny serwer SQL
) wybierz poprawną wersję MariaDB/MySQL. Niektóre narzędzia (np. CLI mysql bez-S
lub-h
) próbują połączyć się z domyślną wersją przez socket.
- W ustawieniach ServBay (
- Brak uprawnień do plików:
- macOS: Proces MariaDB/MySQL może nie mieć praw do katalogu socket lub sam klient nie ma praw do odczytu socketu. ServBay zazwyczaj ustawia uprawnienia prawidłowo, ale ręczne zmiany mogą skutkować błędami.
- Windows: Upewnij się, że użytkownik uruchamiający ServBay może nasłuchiwać na porcie/dostępować do named pipes.
Alternatywa (wymuszenie połączenia sieciowego):
- Spróbuj połączyć się przez IP
127.0.0.1
, zamiastlocalhost
— wymusi wykorzystanie TCP/IP zamiast Unix socket. Jeśli się uda, problem dotyczy socketu.bashmysql -u <username> -p -h 127.0.0.1 -P 3306
1
2. Błąd połączenia: sieć (Connection refused
, Can't connect to MySQL server
)
Tego typu błąd wskazuje, że klient nie może połączyć się z serwerem przez TCP/IP.
Możliwe przyczyny i rozwiązania:
Pakiet nie działa: (patrz wyżej: sprawdź status oraz log błędów
.err
)Zajęty port:
- Upewnij się, że port nasłuchu (domyślnie 3306) nie jest używany przez inny proces.
macOS:
bashlsof -i :3306 # lub netstat -anv | grep LISTEN | grep 3306
1
2
3Windows:
cmdnetstat -an | findstr :3306 # lub PowerShell Get-NetTCPConnection -LocalPort 3306
1
2
3Jeśli port jest zajęty, zatrzymaj przeszkadzający proces lub zmień parametr
port
wmy.cnf
i uruchom ponownie bazę:- macOS:
/Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows:
C:\ServBay\etc\mariadb\<version>\my.cnf
Zapora blokuje połączenie:
macOS:
- Sprawdź systemową zaporę: Preferencje > Sieć > Zapora.
- Tymczasowo zezwól na dostęp dla procesu
mysqld
:bashsudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
1
2
Windows:
- Przejrzyj ustawienia Windows Defender Firewall lub innych narzędzi i dodaj odpowiednią regułę:cmd
netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"
1
Ustawienie
bind-address
:- Sprawdź wpis
bind-address
wmy.cnf
. Wartość127.0.0.1
lublocalhost
pozwala tylko na lokalne połączenia. Dla dostępu z innej maszyny ustaw0.0.0.0
lub konkretny adres IP (pamiętaj o konfiguracji zapory).
- Sprawdź wpis
Problem z rozpoznawaniem
localhost
:- Upewnij się, że
localhost
prawidłowo rozwiązuje się na127.0.0.1
(IPv4) i::1
(IPv6).
macOS:
bashping localhost cat /etc/hosts
1
2Windows:
cmdping localhost type C:\Windows\System32\drivers\etc\hosts
1
2Upewnij się, że plik hosts zawiera właściwe wpisy. Wyłącz proxy: niektóre programy mogą zaburzać połączenia przez
localhost
lub127.0.0.1
.- Upewnij się, że
3. Problem z uruchomieniem MariaDB/MySQL
Możliwe przyczyny i rozwiązania:
Sprawdź log błędów (kluczowe!): Log często wyjaśnia, gdzie tkwi problem z uruchomieniem.
- macOS:
/Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows:
C:\ServBay\logs\mariadb\<version>\<version>.err
- macOS:
Błąd w konfiguracji: Syntax, nieprawidłowy parametr lub ścieżka w pliku konfiguracyjnym.
Lokalizacja
my.cnf
:- macOS:
/Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows:
C:\ServBay\etc\mariadb\<version>\my.cnf
Sprawdzenie poprawności configu:
bash# macOS /Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config # Windows C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf --validate-config
1
2
3
4
5- macOS:
Zajęty port: (patrz wyżej: sprawdź narzędziem
lsof
/netstat
)Brak miejsca na dysku: Na partycji katalogu danych lub logów brakuje wolnego miejsca.
Lokalizacje:
- macOS: dane
/Applications/ServBay/db/mariadb/<version>/
, logi/Applications/ServBay/logs/mariadb/<version>/
- Windows: dane
C:\ServBay\db\mariadb\<version>\
, logiC:\ServBay\logs\mariadb\<version>\
- macOS: dane
Brak odpowiednich uprawnień: Proces nie widzi plików konfiguracyjnych, katalogów danych czy logów. ServBay domyślnie ustawia poprawnie, ale ręczne zmiany mogą powodować błędy.
macOS (sprawdzenie uprawnień):
bashls -ld /Applications/ServBay/db/mariadb/<version> ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf ls -ld /Applications/ServBay/logs/mariadb/<version>
1
2
3Upewnij się, że użytkownik (np.
_mysql
) ma odpowiednie prawa czytania i zapisu.Windows: Skorzystaj z Eksploratora Windows, sprawdź właściwości plików i katalogów.
Uszkodzone pliki danych: (patrz sekcja "Awaria bazy/dane uszkodzone") Nieprawidłowe wyłączenie serwera czy inne błędy mogą uszkodzić pliki i uniemożliwić start.
Po naprawie:
- Spróbuj ponownie uruchomić pakiet:
servbayctl restart mariadb <version>
4. Problemy z uprawnieniami/uwierzytelnianiem użytkownika
Po połączeniu z serwerem możesz spotkać błędy dostępu z powodu błędnego loginu, hasła lub ustawień uprawnień (Access denied
).
Możliwe przyczyny i rozwiązania:
- Zły login lub hasło: Upewnij się, że wpisane dane są poprawne. ServBay pozwala szybko zresetować hasło root — skorzystaj, jeśli je zapomniałeś.
- Ograniczenia hosta użytkownika: Konto może być przypisane tylko do połączeń z określonego hosta (
'<username>'@'localhost'
). Próba logowania przez'127.0.0.1'
może nie działać (i odwrotnie).'%'
oznacza brak ograniczenia hosta. - Brak odpowiednich uprawnień: Użytkownik może nie mieć praw do wybranej bazy lub działań (np. SELECT, INSERT, UPDATE, CREATE, DROP itd).
- Sprawdzenie uprawnień:
- Zaloguj się jako root:bash
mysql -u root -p
1 - Z poziomu SQL przejrzyj uprawnienia użytkownika:sql
SHOW GRANTS FOR '<username>'@'<hostname>'; -- Przykład: uprawnienia użytkownika 'webapp' z hosta 'localhost': SHOW GRANTS FOR 'webapp'@'localhost'; -- Sprawdź użytkownika 'admin' z dowolnego hosta: SHOW GRANTS FOR 'admin'@'%';
1
2
3
4
5 - Jeśli potrzeba, zmodyfikuj uprawnienia poleceniem
GRANT
/REVOKE
lub załóż nowe konto z właściwymi prawami.
- Zaloguj się jako root:
5. Problemy wydajnościowe
Spadek wydajności bazy obniża responsywność aplikacji.
Możliwe przyczyny i rozwiązania:
- Wolne zapytania: Słaba optymalizacja kodu SQL, brak indeksów, zły execution plan.
- Włącz log wolnych zapytań: W
my.cnf
ustawslow_query_log = 1
orazlong_query_time = 1
(logowanie zapytań powyżej 1 sekundy). Sprecyzuj ścieżkę loga przezslow_query_log_file
. Po restarcie analizuj powstały plik. - Użyj
EXPLAIN
: Wstaw przed podejrzanym zapytaniem, sprawdź plan wykonania (czy korzysta z indeksów, liczba przeszukiwanych rekordów itd):sqlEXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
1 - Optymalizuj zapytania: Na podstawie
EXPLAIN
przepisz kod, unikaj nieefektywnych konstrukcji (SELECT *
, użycie funkcji w WHERE), zadbaj o efektywność indeksowania kluczowych kolumn.
- Włącz log wolnych zapytań: W
- Braki indeksów: Brak odpowiednich indeksów na kolumnach używanych do wyszukiwania/sortowania powoduje skanowanie całych tabel.
- Analizuj strukturę tabel i zapytania: Znajdź kolumny do zindeksowania.
- Dodaj indeks:sqlPamiętaj: indeksy zwiększają obciążenie przy zapisie i zajmują miejsce na dysku.
CREATE INDEX idx_column_name ON your_table_name(column_name);
1
- Zła konfiguracja cache: Parametry cache w
my.cnf
(np.innodb_buffer_pool_size
,key_buffer_size
) niedopasowane do maszyny.- Dostosuj pamieć cache: Optymalizuj np.
innodb_buffer_pool_size
do 50-70% dostępnej pamięci systemowej (dla serwera bazodanowego). Zmiany wymagają restartu MariaDB/MySQL:ini[mysqld] # Przykład (dostosuj do RAMu, jednostki: K, M, G) innodb_buffer_pool_size = 2G # Jeśli korzystasz dużo z MyISAM: # key_buffer_size = 256M
1
2
3
4
5
- Dostosuj pamieć cache: Optymalizuj np.
- Braki zasobów sprzętowych: Wysokie zużycie CPU, RAM, problemy z I/O. Monitoruj je przez Activity Monitor macOS lub narzędzia terminalowe (
top
,htop
).
6. Awaria bazy danych lub uszkodzone dane
Brak możliwości startu serwera, ciągłe crash'e, błędy przy odczycie danych — mogą wskazywać na uszkodzenie plików danych.
Możliwe przyczyny i rozwiązania:
- Przejrzyj log błędów: Tam znajdziesz szczegółowe inteligencje nt. awarii — błędy InnoDB, pliki systemowe, błędy sprzętu itd.
- macOS:
/Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows:
C:\ServBay\logs\mariadb\<version>\<version>.err
- macOS:
- Uszkodzenie sprzętu: Błędy dysku, pamięci, itd. Skontroluj raporty systemowe lub uruchom diagnostykę hardware'u.
- Konflikty wersji/Bug: Problem może tkwić w konkretnej wersji MariaDB/MySQL lub interakcji z innym oprogramowaniem.
- Błędna konfiguracja: Złe ustawienia w
my.cnf
mogą wywoływać niestabilność i crash'e serwera. - Brutalne zakończenie procesu: Zamykanie serwera bez procesu stopu ServBay lub killowanie procesu może uszkodzić pliki.
Możliwe działania:
Spróbuj bezpiecznego restartu: Uruchom restart z GUI ServBay lub przez CLI:
servbayctl restart mariadb <version>
. Często baza potrafi automatycznie naprawić pliki.Sprawdzaj i napraw tabelę przez
mysqlcheck
: Służy do oceny integralności oraz (w przypadku MyISAM) naprawy.bashmysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases # W przypadku MyISAM możesz spróbować automatycznej naprawy # mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases
1
2
3Uwaga:
--auto-repair
działa na MyISAM. Przy InnoDB — diagnoza z--check
, naprawa zwykle wymaga innych kroków (np. InnoDB recovery opisane niżej).Wymuszone odzyskiwanie InnoDB (
innodb_force_recovery
): Jeśli silnik InnoDB nie startuje (błędy w logu), możesz podjąć próbę wymuszonego recovery. Opcja ryzykowna, zalecana tylko dla ratowania danych!- Zrób kopię katalogu danych (
/Applications/ServBay/db/mariadb/<version>/
) na wszelki wypadek. - Edytuj plik
my.cnf
(/Applications/ServBay/etc/mariadb/<version>/my.cnf
). - W sekcji
[mysqld]
dodajinnodb_force_recovery = N
(N od 1 w górę do 6 — próbuj po kolei). - Startuj serwer:
servbayctl start mariadb <version>
. - Jeśli uda się uruchomić, natychmiast wykonaj pełny dump danych!bashSprawdź wielkość i integralność pliku backupu!
mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql
1 - Po backupie zatrzymaj serwer:
servbayctl stop mariadb <version>
. - Edytuj
my.cnf
i usuń (lub skomentuj)innodb_force_recovery = N
. - Odzyskuj dane: zwykle poprzez inicjalizację nowego katalogu danych i import backupu.
- Zrób kopię katalogu danych (
Przywracanie z backupu: Jeśli naprawa się nie uda lub dane nie są spójne, najpewniejszą opcją jest odtworzenie z kopii zapasowej. Pliki backupu ServBay znajdziesz tu:
/Applications/ServBay/backup/mariadb/<version>/
.- Przykład odtworzenia (dla
<target_database_name>
):bashUwaga: Zastąp# Najpierw utwórz bazę docelową # mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;" # Importuj backup do bazy mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
1
2
3
4
5<version>
właściwą wersją MariaDB/MySQL.
- Przykład odtworzenia (dla
7. Problemy z backupem i przywracaniem
Podczas użycia narzędzi ServBay (lub ręcznego mysqldump
) mogą pojawić się komplikacje związane z backupem/odtworzeniem.
Możliwe przyczyny i rozwiązania:
- Niepełny lub uszkodzony plik backupu:
- Sprawdź rozmiar pliku (
ls -lh /path/to/your_backup.sql
), czy odpowiada oczekiwanym danym. - Podgląd zawartości przez edytor tekstowy lub
less
(less /path/to/your_backup.sql
) — sprawdź, czy przypomina poprawny SQL. - Jeśli backup wykonywany był ręcznie przez mysqldump, sprawdź komunikaty w trakcie. Backupy ServBay mają swoje logi w aplikacji.
- Sprawdź rozmiar pliku (
- Błędy komend podczas przywracania:
- Błędna nazwa użytkownika, hasło lub baza.
- Brak odpowiednich uprawnień użytkownika do importowania.
- Błędy składni SQL: przy migracji pomiędzy różnymi wersjami lub MariaDB ↔ MySQL mogą pojawić się niekompatybilności.
- Problemy z kluczami obcymi: Kolejność importu tabel może zaburzać spójność kluczy. Przed importem wyłącz sprawdzanie kluczy:sqlUwaga: Przy wyłączonych kluczach mogą pojawić się niespójności — korzystaj tylko tymczasowo.
-- Przed importem SET foreign_key_checks = 0; -- Importuj plik .sql: source /path/to/your_backup.sql w kliencie mysql -- Lub: mysql ... < /path/to/your_backup.sql -- Po imporcie SET foreign_key_checks = 1;
1
2
3
4
5
6
7 - Kwestie kodowania znaków/sortowania: Backup .sql może działać na innym zestawie znaków/sortowaniu niż baza docelowa. Sprawdź kompatybilność (np. zalecane
utf8mb4
).
Poprawny import bazy (przykład CLI):
macOS:
bash
# Jeśli backup dotyczy jednej bazy
# Najpierw utwórz bazę
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
# Import danych
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
# Dla backupu wszystkich baz (--all-databases) nie podawaj nazwy
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
Windows:
cmd
REM Jeśli backup dotyczy jednej bazy
REM Najpierw utwórz bazę
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
REM Import danych
C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p <target_database_name> < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>
REM Dla backupu wszystkich baz (--all-databases) nie podawaj nazwy
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
Uwaga: <version>
to numer wersji. Backupy ServBay mają optymalny format do importu i opcje odtworzenia w GUI.
8. Znany Bug: MariaDB 11.5.1 InnoDB — problem uruchomienia (ib_logfile0 was not found
/ Missing FILE_CHECKPOINT
)
W MariaDB 11.5.1 występuje poważny błąd, uniemożliwiający inicjalizację silnika InnoDB — brak pliku logu lub checkpoint logu powoduje, że baza nie startuje.
Objawy w logu błędów:
W plikach logów znajdziesz błędy podobne do:
macOS (/Applications/ServBay/logs/mariadb/11.5/11.5.err
):
[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
2
3
4
Windows (C:\ServBay\logs\mariadb\11.5\11.5.err
):
[ERROR] InnoDB: File C:\ServBay\db\mariadb\11.5\ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
2
3
4
Lub:
[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB
1
2
3
4
5
2
3
4
5
Takie komunikaty oznaczają, że InnoDB nie może mieć dostępu do plików logów, przez co cały silnik się nie uruchamia.
Rozwiązanie (wymaga migracji danych — najpierw backup!):
To poważny błąd, trudny do naprawienia standardowymi metodami. Najlepiej wymusić start bazy celem eksportu danych i przejść na stabilną wersję MariaDB.
Próba wymuszonego recovery i backupu (ryzykowne!):
Edytuj config:
- macOS:
/Applications/ServBay/etc/mariadb/11.5/my.cnf
- Windows:
C:\ServBay\etc\mariadb\11.5\my.cnf
Dodaj w sekcji
[mysqld]
:innodb_force_recovery = 6
Start serwera:
bashservbayctl start mariadb 11.5
1Jeżeli serwer się uruchomi — od razu wykonaj backup:
macOS:
bashmysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql
1Windows:
cmdC:\ServBay\bin\mariadb\11.5\bin\mysqldump.exe --defaults-file=C:\ServBay\etc\mariadb\11.5\my.cnf -u root -p --all-databases --routines --triggers --events > C:\ServBay\backup\mariadb\11.5\mariadb_11.5_emergency_backup.sql
1Sprawdź, czy backup się wygenerował oraz czy ma odpowiedni rozmiar.
- macOS:
Zatrzymaj problematyczny serwer i zarządzaj katalogiem danych:
- Zatrzymaj MariaDB 11.5:
servbayctl stop mariadb 11.5
- Edytuj plik
my.cnf
i usuń lub zakomentujinnodb_force_recovery...
- Zatrzymaj MariaDB 11.5: