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 lub 11.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:

1. 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:

   servbayctl status mariadb <version>
   # Przykład sprawdzenia statusu MariaDB 11.3:
   servbayctl status mariadb 11.3

2. Przejrzyj logi aplikacji ServBay: Błędy mogą być zapisane w sekcji logów interfejsu ServBay lub w głównym pliku logów aplikacji.

3. Sprawdź log błędów MariaDB/MySQL: Kluczowy krok w przypadku awarii startu czy błędów runtime. Lokalizacja pliku logu:

   macOS:

   /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

   Windows:

   C:\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"

   Przeczytaj 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).
• 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.
• 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.
• 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, zamiast localhost — wymusi wykorzystanie TCP/IP zamiast Unix socket. Jeśli się uda, problem dotyczy socketu.

  mysql -u <username> -p -h 127.0.0.1 -P 3306

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:

  lsof -i :3306
  # lub
  netstat -anv | grep LISTEN | grep 3306

  Windows:

  netstat -an | findstr :3306
  # lub PowerShell
  Get-NetTCPConnection -LocalPort 3306

  Jeśli port jest zajęty, zatrzymaj przeszkadzający proces lub zmień parametr port w my.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:

    sudo /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

  Windows:

  • Przejrzyj ustawienia Windows Defender Firewall lub innych narzędzi i dodaj odpowiednią regułę:

    netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"

• Ustawienie bind-address:

  • Sprawdź wpis bind-address w my.cnf. Wartość 127.0.0.1 lub localhost pozwala tylko na lokalne połączenia. Dla dostępu z innej maszyny ustaw 0.0.0.0 lub konkretny adres IP (pamiętaj o konfiguracji zapory).

• Problem z rozpoznawaniem localhost:

  • Upewnij się, że localhost prawidłowo rozwiązuje się na 127.0.0.1 (IPv4) i ::1 (IPv6).

  macOS:

  ping localhost
  cat /etc/hosts

  Windows:

  ping localhost
  type C:\Windows\System32\drivers\etc\hosts

  Upewnij się, że plik hosts zawiera właściwe wpisy. Wyłącz proxy: niektóre programy mogą zaburzać połączenia przez localhost lub 127.0.0.1.

3. Problem z uruchomieniem MariaDB/MySQL

Możliwe przyczyny i rozwiązania:

1. 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

2. 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:

   # 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

3. Zajęty port: (patrz wyżej: sprawdź narzędziem lsof/netstat)

4. 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>\, logi C:\ServBay\logs\mariadb\<version>\

5. 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ń):

   ls -ld /Applications/ServBay/db/mariadb/<version>
   ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
   ls -ld /Applications/ServBay/logs/mariadb/<version>

   Upewnij 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.

6. 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:

    mysql -u root -p

  • Z poziomu SQL przejrzyj uprawnienia użytkownika:

    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'@'%';

  • Jeśli potrzeba, zmodyfikuj uprawnienia poleceniem GRANT/REVOKE lub załóż nowe konto z właściwymi prawami.

5. Problemy wydajnościowe

Spadek wydajności bazy obniża responsywność aplikacji.

Możliwe przyczyny i rozwiązania:

1. Wolne zapytania: Słaba optymalizacja kodu SQL, brak indeksów, zły execution plan.
   • Włącz log wolnych zapytań: W my.cnf ustaw slow_query_log = 1 oraz long_query_time = 1 (logowanie zapytań powyżej 1 sekundy). Sprecyzuj ścieżkę loga przez slow_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):

     EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';

   • Optymalizuj zapytania: Na podstawie EXPLAIN przepisz kod, unikaj nieefektywnych konstrukcji (SELECT *, użycie funkcji w WHERE), zadbaj o efektywność indeksowania kluczowych kolumn.
2. 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:

     CREATE INDEX idx_column_name ON your_table_name(column_name);

     Pamiętaj: indeksy zwiększają obciążenie przy zapisie i zajmują miejsce na dysku.
3. 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:

     [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

4. 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:

1. 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
2. Uszkodzenie sprzętu: Błędy dysku, pamięci, itd. Skontroluj raporty systemowe lub uruchom diagnostykę hardware'u.
3. Konflikty wersji/Bug: Problem może tkwić w konkretnej wersji MariaDB/MySQL lub interakcji z innym oprogramowaniem.
4. Błędna konfiguracja: Złe ustawienia w my.cnf mogą wywoływać niestabilność i crash'e serwera.
5. 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.

  mysqlcheck --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

  Uwaga: --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!

  1. Zrób kopię katalogu danych (/Applications/ServBay/db/mariadb/<version>/) na wszelki wypadek.
  2. Edytuj plik my.cnf (/Applications/ServBay/etc/mariadb/<version>/my.cnf).
  3. W sekcji [mysqld] dodaj innodb_force_recovery = N (N od 1 w górę do 6 — próbuj po kolei).
  4. Startuj serwer: servbayctl start mariadb <version>.
  5. Jeśli uda się uruchomić, natychmiast wykonaj pełny dump danych!

     mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql

     Sprawdź wielkość i integralność pliku backupu!
  6. Po backupie zatrzymaj serwer: servbayctl stop mariadb <version>.
  7. Edytuj my.cnf i usuń (lub skomentuj) innodb_force_recovery = N.
  8. Odzyskuj dane: zwykle poprzez inicjalizację nowego katalogu danych i import backupu.

• 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>):

    # 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>

    Uwaga: Zastąp <version> właściwą wersją MariaDB/MySQL.

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.
• 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:

  -- 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;

  Uwaga: Przy wyłączonych kluczach mogą pojawić się niespójności — korzystaj tylko tymczasowo.
• 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:

# 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>

Windows:

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>

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

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

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

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.

1. 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:

   servbayctl start mariadb 11.5

   Jeżeli serwer się uruchomi — od razu wykonaj backup:

   macOS:

   mysqldump --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

   Windows:

   C:\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

   Sprawdź, czy backup się wygenerował oraz czy ma odpowiedni rozmiar.

2. Zatrzymaj problematyczny serwer i zarządzaj katalogiem danych:

   • Zatrzymaj MariaDB 11.5: servbayctl stop mariadb 11.5
   • Edytuj plik my.cnf i usuń lub zakomentuj innodb_force_recovery...