Przewodnik rozwiązywania problemów z pakietem ServBay MariaDB/MySQL

Przegląd

MariaDB i MySQL to wiodące w branży otwarte relacyjne systemy zarządzania bazami danych, szeroko wykorzystywane w rozmaitych aplikacjach internetowych i biznesowych przypadkach użycia. ServBay integruje wiele wersji pakietów MariaDB/MySQL w środowisku macOS, zapewniając deweloperom wygodne i efektywne lokalne środowisko bazy danych. Pomimo swojej stabilności, podczas tworzenia i uruchamiania mogą wystąpić problemy takie jak nieudane uruchomienie pakietu, błędy połączeń czy spadki wydajności.

Niniejszy przewodnik ma pomóc użytkownikom ServBay w diagnozowaniu i rozwiązywaniu najczęstszych problemów z pakietem MariaDB/MySQL. Obejmujemy główne przypadki, kroki diagnozy i konkretne rozwiązania, ze szczególnym uwzględnieniem dedykowanych ścieżek i poleceń charakterystycznych dla ServBay.

Ważne wskazówki:

• Przed wykonaniem jakichkolwiek działań mogących zmienić dane lub konfigurację, koniecznie wykonaj kopię zapasową bazy danych! ServBay posiada wbudowaną funkcję backupu, z której zaleca się regularnie korzystać.
• Przykłady poleceń i ścieżek używają określonych wersji (np. 11.3 lub 11.5); zastąp te wersje faktycznie używanymi w Twoim ServBay. Numer wersji można sprawdzić w interfejsie aplikacji ServBay.
• W przykładach poleceń, placeholdery takie jak <username>, <database>, <your_backup.sql> należy zastąpić odpowiednimi wartościami dla Twojego systemu.
• Przewodnik koncentruje się na systemie operacyjnym macOS.

Uniwersalne wstępne kroki diagnostyczne

Zanim przejdziesz do szczegółowych analiz, wykonaj poniższe podstawowe kontrole:

1. Sprawdź status pakietu ServBay: Otwórz interfejs aplikacji ServBay i upewnij się, że wybrana wersja MariaDB/MySQL jest aktywna i oznaczona jako „Uruchomiona”. Możesz to też sprawdzić w terminalu:

   servbayctl status mariadb <version>
   # Np. sprawdzenie statusu MariaDB 11.3:
   servbayctl status mariadb 11.3

2. Sprawdź logi aplikacji ServBay: Czasami ServBay zapisuje błędy podczas próby uruchomienia lub zarządzania pakietami. Zajrzyj do sekcji logów w interfejsie ServBay lub sprawdź główny plik logów aplikacji.
3. Sprawdź log błędów MariaDB/MySQL: To kluczowy krok w lokalizowaniu problemów z uruchamianiem czy błędami czasu rzeczywistego. Domyślna ścieżka logu:

   /Applications/ServBay/logs/mariadb/<version>/<version>.err
   # Np. przejrzenie ostatnich 50 linii logu błędów MariaDB 11.3:
   tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

   Zwróć szczególną uwagę na końcowe błędy w logu – często precyzyjnie wskazują źródło problemu.

Najczęstsze problemy i rozwiązania

1. Błąd połączenia: SQLSTATE[HY000] [2002] No such file or directory

Ten błąd zwykle oznacza, że klient nie może połączyć się z serwerem MariaDB/MySQL przez Unix socket. Na macOS Unix socket jest mechanizmem komunikacji międzyprocesowej na tej samej maszynie i jest preferowany nad połączeniami TCP/IP ze względu na wydajność. Jeżeli aplikacja lub narzędzie CLI próbuje połączyć się przez socket, którego nie może znaleźć, występuje taki błąd.

Możliwe przyczyny i rozwiązania:

• Pakiet MariaDB/MySQL nie jest uruchomiony:
  • Sprawdź w GUI ServBay lub przez servbayctl status mariadb <version>, czy pakiet działa.
  • Jeśli nie, uruchom go poleceniem servbayctl start mariadb <version> i sprawdź log błędów (.err) dla dalszych informacji.
• Nieprawidłowa ścieżka do pliku socket:
  • Używana ścieżka socket przez klienta nie zgadza się z tą w konfiguracji serwera (my.cnf).
  • Sprawdź parametr socket w pliku konfiguracyjnym /Applications/ServBay/etc/mariadb/<version>/my.cnf.
  • Upewnij się, że Twoja aplikacja lub klient używa prawidłowej domyślnej ścieżki ServBay do socket, np. /Applications/ServBay/tmp/mysql.sock lub /tmp/mysql.sock.
• Błąd ustawień domyślnych ServBay:
  • W ustawieniach ServBay („Ustawienia” -> „Domyślny serwer SQL”) sprawdź, czy właściwa wersja MariaDB/MySQL jest ustawiona jako domyślna. Niektóre narzędzia (np. mysql bez definicji -S lub -h) mogą próbować łączyć się z domyślną wersją przez socket.
• Problemy z uprawnieniami:
  • Użytkownik uruchamiający proces MariaDB/MySQL nie ma praw do zapisu w katalogu, w którym tworzony jest socket, albo klient nie ma prawa do odczytu tego pliku. ServBay zwykle właściwie ustawia uprawnienia, ale własnoręczne zmiany w /Applications/ServBay/tmp/ lub /tmp/ mogą je zaburzyć.

Alternatywa (wymuszenie połączenia sieciowego):

• Spróbuj połączyć się przez adres IP 127.0.0.1 zamiast localhost. To wymusza użycie TCP/IP zamiast Unix socketu. Jeśli takie połączenie działa, problem na pewno dotyczy pliku socket.

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

2. Błąd połączenia: błędy sieciowe (np. Connection refused, Can't connect to MySQL server)

Tego typu błędy oznaczają, że klient nie może połączyć się z serwerem MariaDB/MySQL przez TCP/IP.

Możliwe przyczyny i rozwiązania:

• Pakiet MariaDB/MySQL nie jest uruchomiony: (jak wyżej – sprawdź status, log .err)
• Port jest zajęty:
  • Upewnij się, że port nasłuchu (domyślnie 3306) nie jest używany przez inny proces.
  • Sprawdź zajętość portu:

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

  • Jeśli port jest zajęty, zatrzymaj zawłaszczający proces lub zmień port w pliku konfiguracyjnym MariaDB/MySQL (/Applications/ServBay/etc/mariadb/<version>/my.cnf – parametr port) i zrestartuj pakiet.
• Firewall blokuje połączenie:
  • Zestaw firewall macOS lub aplikacja trzecia może blokować dostęp do portu 3306.
  • Sprawdź Ustawienia systemowe -> Sieć -> Firewall.
  • Zezwól tymczasowo na komunikację procesu mysqld. Ścieżka do mysqld może się różnić w zależności od wersji ServBay:

    # Przykładowe polecenia – dostosuj ścieżkę do swojego środowiska
    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

• Błąd konfiguracji (bind-address):
  • Sprawdź parametr bind-address w pliku my.cnf. Jeśli jest ustawiony na 127.0.0.1 lub localhost, serwer akceptuje tylko połączenia z localhost. Aby połączyć się z innych maszyn/VM, ustaw 0.0.0.0 lub wybrany adres IP i upewnij się, że firewall to umożliwia.
• Problemy z rozpoznawaniem localhost:
  • Sprawdź, czy localhost poprawnie wskazuje na 127.0.0.1 (IPv4) i ::1 (IPv6).
  • Zrób test ping localhost w terminalu.
  • Sprawdź zawartość /etc/hosts, czy zawiera prawidłowy wpis dla localhost.
  • Wyłącz serwery proxy – niektóre mogą blokować ruch do/z localhost/127.0.0.1.

3. Pakiet MariaDB/MySQL nie uruchamia się

Możliwe przyczyny i rozwiązania:

1. Sprawdź log błędów (kluczowe!): Zajrzyj do /Applications/ServBay/logs/mariadb/<version>/<version>.err, by znaleźć konkretną przyczynę nieudanego uruchomienia. Logi są najważniejszym źródłem informacji.
2. Błąd w pliku konfiguracyjnym:
   • Plik /Applications/ServBay/etc/mariadb/<version>/my.cnf może mieć błędy składniowe lub nieprawidłowe parametry/ścieżki.
   • Sprawdź poprawność konfiguracji (uwaga na ścieżkę do mysqld dla swojego pakietu):

     # Przykładowa komenda – dostosuj ścieżki do swojej instalacji
     /Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config

3. Zajęty port: (jak wyżej – użyj lsof -i :<port> lub netstat aby sprawdzić)
4. Brak miejsca na dysku: Katalog danych bazy (/Applications/ServBay/db/mariadb/<version>/) lub katalog logów (/Applications/ServBay/logs/mariadb/<version>/) mogą znajdować się na zapełnionej partycji. Baza potrzebuje miejsca na dane, logi i pliki tymczasowe.
5. Problemy z uprawnieniami:
   • Użytkownik uruchamiający proces (_mysql lub inny używany przez ServBay) może nie mieć wystarczających praw do plików konfiguracyjnych, katalogu z danymi czy z logami. Jeśli ręcznie zmieniono prawa w /Applications/ServBay, to może to blokować uruchomienie.
   • Sprawdź uprawnienia przykładowo:

     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 bazy ma dostęp odczytu/zapisu.
6. Uszkodzone pliki danych: (patrz sekcja „Awaria bazy lub uszkodzenie danych” niżej) Jeśli ostatnie zamknięcie było nagłe czy był inny problem, pliki danych mogły się uszkodzić.

Po rozwiązaniu wykrytych problemów:

• Spróbuj ponownie uruchomić pakiet: servbayctl restart mariadb <version>

4. Problemy z uprawnieniami użytkownika lub autoryzacją

Po nawiązaniu połączenia z serwerem możesz otrzymać błędy związane z nazwą użytkownika, hasłem lub uprawnieniami (np. Access denied).

Możliwe przyczyny i rozwiązania:

• Błędna nazwa użytkownika lub hasło: Sprawdź dokładność danych logowania. ServBay pozwala łatwo zresetować hasło użytkownika root.
• Ograniczenie po stronie hosta: Konto może być ograniczone tylko do określonego hosta, np. '<username>'@'localhost'. Próba połączenia z '<username>'@'127.0.0.1' może się nie powieść. Znak '%' oznacza dowolny host.
• Niewystarczające uprawnienia: Użytkownik może nie mieć wystarczających praw do wykonania żądanej operacji (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP itd.).
• Sprawdzenie uprawnień:
  • Zaloguj się na konto z uprawnieniami administracyjnymi (np. root):

    mysql -u root -p

  • W konsoli SQL przejrzyj uprawnienia wybranego użytkownika:

    SHOW GRANTS FOR '<username>'@'<hostname>';
    -- Np. sprawdzenie uprawnień 'webapp' dla 'localhost':
    SHOW GRANTS FOR 'webapp'@'localhost';
    -- Uprawnienia dla 'admin' dostępnego z dowolnego hosta:
    SHOW GRANTS FOR 'admin'@'%';

  • W razie potrzeby zmodyfikuj uprawnienia poleceniami GRANT lub REVOKE, lub utwórz nowe konto i przyznaj konieczne uprawnienia.

5. Problemy z wydajnością

Spadek wydajności bazy ma wpływ na szybkość działania całej aplikacji.

Możliwe przyczyny i rozwiązania:

1. Wolne zapytania: Zbyt wolne zapytania, brak indeksów, zła strategia wykonania.
   • Włącz logowanie wolnych zapytań: W my.cnf ustaw slow_query_log = 1 i long_query_time = 1 (logowanie zapytań trwających powyżej 1 sekundy) oraz wskaż plik slow_query_log_file. Po restarcie analizuj log i znajdź najwolniejsze zapytania.
   • Użyj EXPLAIN: Dodaj do problematycznego zapytania słowo kluczowe EXPLAIN, aby sprawdzić, jak baza je realizuje, czy używa indeksów, ile rekordów skanuje itd.

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

   • Optymalizuj zapytanie: Na podstawie analizy EXPLAIN popraw zapytanie, unikaj nieefektywnych konstrukcji (np. SELECT *, używanie funkcji w WHERE), zadbaj o indeksy na właściwych kolumnach.
2. Brak lub niewłaściwe indeksy: Brak indeksów na kolumnach używanych w WHERE, JOIN, ORDER BY lub GROUP BY.
   • Przeanalizuj strukturę tabel i typowe zapytania: Określ, gdzie potrzebne są indeksy.
   • Tworzenie indeksów:

     CREATE INDEX idx_column_name ON your_table_name(column_name);

     Uwaga: Indeksy przyspieszają odczyty, ale spowalniają zapisy i zajmują miejsce na dysku – ważna jest równowaga.
3. Nieoptymalne ustawienia buforowania: Za małe lub zbyt duże wartości w my.cnf dla parametrów takich jak innodb_buffer_pool_size, key_buffer_size (dla MyISAM).
   • Dostosuj konfigurację: Dopasuj parametry do ilości wolnej pamięci RAM i zastosowań bazy. Najważniejsze dla InnoDB to innodb_buffer_pool_size – zalecane 50–70% dostępnego RAM dla serwera bazodanowego. Po zmianie parametrów wymagany jest restart pakietu.

     [mysqld]
     # Przykład - dostosuj do swojego sprzętu, rozmiary mogą być w B, K, M, G
     innodb_buffer_pool_size = 2G
     # Jeśli używasz dużo MyISAM:
     # key_buffer_size = 256M

4. Bariery sprzętowe: Zbyt obciążony CPU, brak pamięci RAM, zbyt wolny dysk. Użyj Monitor aktywności w macOS lub komend takich jak top czy htop do śledzenia użycia CPU, RAM, dysku i sieci, by wskazać bottleneck.

6. Awaria bazy danych lub uszkodzenie danych

Problemy z uruchamianiem bazy, częste awarie lub błędy dostępu do danych często mają związek z uszkodzeniem plików danych.

Możliwe przyczyny i rozwiązania:

1. Sprawdzenie logu błędów: Zawsze zaczynaj od logu /Applications/ServBay/logs/mariadb/<version>/<version>.err – znajdziesz w nim powody awarii, np. błędy InnoDB, plików systemowych lub sprzętu.
2. Problemy sprzętowe: Błędy dysku, RAM, zasilania mogą prowadzić do uszkodzenia danych. Sprawdź logi systemowe (Konsola) lub użyj narzędzi diagnostycznych hardware.
3. Konflikt aplikacji lub bug: Pewne wersje MariaDB/MySQL mogą mieć błędy lub kolidować z innymi aplikacjami w systemie.
4. Błąd konfiguracji: Niewłaściwe parametry w my.cnf powodują niestabilność bazy.
5. Nagłe przerwanie działania: Siłowe zamknięcie bazy (np. brutalne wyłączenie ServBay albo kill -9 procesu) prowadzi do niespójnych plików danych.

Rozwiązania:

• Spróbuj bezpiecznego restartu: Użyj GUI ServBay lub w terminalu servbayctl restart mariadb <version>. Czasem sam restart uruchomi samonaprawę bazy.
• Użyj mysqlcheck dla kontroli i naprawy tabel: Narzędzie pozwala sprawdzić integralność tabel oraz naprawić niektóre uszkodzenia (głównie MyISAM).

  # Sprawdzanie wszystkich baz, wszystkich tabel z użyciem configu ServBay i konta root
  mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
  # Automatyczna naprawa dla MyISAM:
  # mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

  Uwaga: --auto-repair działa wyłącznie na MyISAM. W przypadku InnoDB konieczne są zaawansowane procedury (patrz poniżej: wymuszona naprawa lub przywracanie z backupu).
• Wymuszone odzyskiwanie InnoDB (innodb_force_recovery): Jeśli InnoDB nie startuje (błędy w logu), użyj tej opcji. Uwaga, ryzyko utraty danych! Używaj tylko, jeśli nie da się uruchomić bazy w żaden inny sposób i liczy się tylko eksport danych.
  1. Koniecznie zrób backup całego katalogu danych (nawet jeśli już uszkodzony): Skopiuj /Applications/ServBay/db/mariadb/<version>/ gdzie indziej.
  2. Edytuj my.cnf dla problemowej wersji (/Applications/ServBay/etc/mariadb/<version>/my.cnf).
  3. W sekcji [mysqld] dopisz: innodb_force_recovery = N (gdzie N to liczba od 1–6, zaczynaj od 1, podnoś stopniowo przy braku efektu – ZAWSZE testuj jedną wartość na raz!).
  4. Uruchom serwer: servbayctl start mariadb <version>.
  5. Jeśli serwer wystartuje (nawet w trybie tylko do odczytu), natychmiast zrób backup wszystkich danych przez mysqldump!

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

     Koniecznie sprawdź, czy backup się utworzył i ma właściwą wielkość.
  6. Po kopii zapasowej zatrzymaj bazę: servbayctl stop mariadb <version>
  7. Edytuj my.cnf i usuń lub skomentuj linię innodb_force_recovery = N.
  8. Rozpocznij przywracanie danych: Zazwyczaj konieczna jest inicjalizacja nowego katalogu danych i import kopii zapasowej.
• Przywracanie z backupu: Jeśli nie uda się naprawić bazy lub dane są niespójne, najlepszym sposobem jest powrót do najnowszej poprawnej kopii zapasowej. Backup zostaje zapisany w: /Applications/ServBay/backup/mariadb/<version>/ (jeśli używasz mechanizmu ServBay).
  • Przykład przywrócenia backupu do wybranej bazy <target_database_name>:

    # Upewnij się, że baza docelowa istnieje
    # mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
    
    # Import backupu
    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: <version> należy zastąpić wersją docelowego pakietu MariaDB/MySQL.

7. Problemy podczas backupu i przywracania

Podczas korzystania z backupu ServBay lub ręcznego mysqldump/odtwarzania mogą pojawić się błędy.

Możliwe przyczyny i rozwiązania:

• Niekompletny lub uszkodzony plik backupu:
  • Sprawdź rozmiar pliku (ls -lh /path/to/your_backup.sql), czy odpowiada oczekiwanej ilości danych.
  • Przejrzyj zawartość pliku (less /path/to/your_backup.sql), czy wygląda jak poprawny plik SQL.
  • Jeśli backup był ręczny (mysqldump), sprawdź, czy polecenie nie pokazało błędów. Dla backupów ServBay zajrzyj do logów aplikacji.
• Błąd polecenia przywracania:
  • Niepoprawny użytkownik, hasło lub nazwa bazy docelowej.
  • Zbyt niskie uprawnienia użytkownika.
  • Błędy w składni SQL - backupy z różnych wersji/baz czasem są niekompatybilne.
• Problemy z kluczami obcymi: Kolejność importu tabel może powodować błędy – referencje do nieistniejących tabel. Przed importem tymczasowo wyłącz sprawdzanie kluczy obcych:

  -- Przed importem
  SET foreign_key_checks = 0;
  -- Import, np.:
  source /path/to/your_backup.sql; -- wykonywane w kliencie mysql
  -- lub przez polecenie shellowe: mysql ... < /path/to/your_backup.sql
  
  -- Po zakończeniu importu:
  SET foreign_key_checks = 1;

  Uwaga: Wyłączanie kluczy obcych może prowadzić do niespójności – stosuj wyłącznie podczas importu.
• Błędne kodowanie lub sortowanie (collation): Backup może używać innego kodowania lub sortowania niż baza docelowa, co prowadzi do błędów lub krzaków. Upewnij się, że ustawienia baz/tabel są zgodne (np. utf8mb4).

Poprawny import bazy (przykład w terminalu):

# Jeśli backup dotyczy jednej konkretnej bazy
# Upewnij się, że baza docelowa (<target_database_name>) istnieje
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Import przez wskazanie prawidłowego pliku konfiguracyjnego, użytkownika, hasła i 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>

# Przy backupie wszystkich baz (--all-databases) nie podawaj bazy:
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Uwaga: <version> należy zastąpić odpowiednią wersją MariaDB/MySQL. Backupy ServBay są zapisane w formacie łatwym do odtworzenia i mają swoje opcje przywracania.

8. Znany bug: MariaDB 11.5.1, błąd uruchomienia InnoDB (ib_logfile0 was not found / Missing FILE_CHECKPOINT)

Jest to poważny, znany bug w MariaDB 11.5.1, mogący uniemożliwić poprawną inicjalizację silnika InnoDB lub odtworzenie z logów – przez co baza nie uruchamia się.

Jak rozpoznać ten problem w logach:

W /Applications/ServBay/logs/mariadb/11.5/11.5.err mogą pojawić się m.in.:

[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

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

To oznacza, że InnoDB nie jest w stanie znaleźć lub przetworzyć plików logu i przez to nie działa.

Rozwiązanie (wymaga eksportu i migracji – najpierw zrób kopię zapasową!):

Są to błędy trudne do naprawienia zwykłymi metodami. Najlepiej wymusić start bazy, wyeksportować dane i przenieść je na stabilną wersję MariaDB.

1. Spróbuj wymuszonego odzyskania danych (ryzyko straty!):
   • Edytuj plik konfiguracji /Applications/ServBay/etc/mariadb/11.5/my.cnf dla MariaDB 11.5.
   • W sekcji [mysqld] dodaj linię: innodb_force_recovery = 6
   • Spróbuj uruchomić: servbayctl start mariadb 11.5
   • Jeśli baza ruszy (choćby z ograniczonymi funkcjami), NATYCHMIAST zrób backup wszystkiego (mysqldump)!

     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

     Sprawdź, czy plik kopii zapasowej się utworzył i ma odpowiedni rozmiar.
2. Zatrzymaj bazę i wykonaj dalsze kroki migracyjne:
   • Zatrzymaj pakiet MariaDB 11.5: servbayctl stop mariadb 11.5
   • Edytuj plik my.cnf i usuń lub skomentuj linię innodb_force_recovery = 6.