ServBay MariaDB/MySQL Fehlerbehebungsleitfaden

Überblick

MariaDB und MySQL sind die führenden Open-Source-Datenbanksysteme und werden in verschiedensten Webanwendungen und Geschäftsszenarien eingesetzt. ServBay integriert mehrere Versionen von MariaDB/MySQL unter macOS und Windows und bietet Entwicklern eine effiziente, lokale Datenbankumgebung. Trotz ihrer stabilen Architektur können während der Entwicklung und des Betriebs dennoch Probleme wie Startfehler, Verbindungsabbrüche oder Performance-Einbußen auftreten.

Dieser Leitfaden hilft ServBay-Nutzenden dabei, typische Fehler mit MariaDB/MySQL-Paketen zu erkennen und zu beheben. Es werden verbreitete Probleme, Diagnosewege und Lösungen beschrieben, inklusive versionenspezifischer ServBay-Pfade und -Befehle.

Wichtige Hinweise:

Sichern Sie Ihre Datenbank unbedingt, bevor Sie Änderungen an Daten oder Konfiguration vornehmen! ServBay bietet eine integrierte Backup-Funktion – nutzen Sie diese regelmäßig!
Beispielhafte Befehle und Pfade im Text verwenden feste Versionsnummern (z. B. 11.3 oder 11.5). Ersetzen Sie diese entsprechend Ihrer installierten MariaDB/MySQL-Version, die Sie über die ServBay-Oberfläche einsehen können.
Platzhalter wie <username>, <database>, <your_backup.sql> sollten durch Ihre tatsächlichen Werte ersetzt werden.
Dieser Leitfaden gilt für macOS und Windows. Versions- und betriebssystemspezifische Befehle und Pfade sind in den jeweiligen Abschnitten explizit genannt.

Allgemeine Schritte zur ersten Problemdiagnose

Führen Sie diese Basischecks durch, bevor Sie sich an die detaillierte Fehlersuche machen:

Status des ServBay Datenbankpaketes prüfen: Öffnen Sie die ServBay-Oberfläche und vergewissern Sie sich, dass Ihr gewünschtes MariaDB/MySQL-Paket aktiviert und als „läuft“ angezeigt wird. Alternativ können Sie dies per Terminal prüfen:
bash
```
servbayctl status mariadb <version>
# Beispiel für MariaDB 11.3:
servbayctl status mariadb 11.3
```
1
2
3
ServBay-Logs einsehen: Fehler beim Start oder der Paketverwaltung werden oft in der Log-Sektion der ServBay-Oberfläche oder in den Hauptprotokolldateien protokolliert.

Fehlerprotokolle für MariaDB/MySQL prüfen: Die Fehlerlogs sind unerlässlich, um Startprobleme oder Laufzeitfehler einzugrenzen. Die typischen Speicherorte sind:

macOS:

bash

/Applications/ServBay/logs/mariadb/<version>/<version>.err
# Die letzten 50 Zeilen aus dem Error-Log von MariaDB 11.3 anzeigen:
tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

Windows:

cmd

C:\ServBay\logs\mariadb\<version>\<version>.err
# Die letzten 50 Zeilen aus dem Error-Log von MariaDB 11.3 anzeigen:
powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"

Überfliegen Sie vor allem die letzten Fehlermeldungen – sie geben meist direkt Aufschluss über die Ursache.

Häufige Probleme und Lösungswege

1. Verbindungsfehler: `SQLSTATE[HY000] [2002] No such file or directory`

Dieser Fehler deutet darauf hin, dass der Client die Verbindung über eine Unix-Socket-Datei nicht herstellen kann. Unter macOS ist der Unix-Socket ein Mechanismus für lokale Prozesskommunikation, der effizienter als TCP/IP ist. Trifft die Anwendung oder das CLI-Tool den konfigurierten Socket-Pfad nicht, erscheint dieser Fehler.

Mögliche Ursachen und Lösungen:

MariaDB/MySQL läuft nicht:
- Kontrollieren Sie den Status in ServBay oder mit servbayctl status mariadb <version>.
- Starten Sie ggfs. die Datenbank mit: servbayctl start mariadb <version> und prüfen das Fehlermodul (.err).
Falscher Socket-Pfad (nur macOS/Linux):
- Der Socket-Pfad in der Verbindung muss mit dem Pfad im Server-Config-File (my.cnf) übereinstimmen.
- macOS: Überprüfen Sie die Einstellung des socket-Parameters in /Applications/ServBay/etc/mariadb/<version>/my.cnf.
- Windows: Windows nutzt keine Unix-Sockets, sondern Named Pipes oder TCP/IP.
- macOS: Achten Sie darauf, dass Clients und Applikationen den korrekten Socket-Pfad nutzen. Standardmäßig liegt er bei /Applications/ServBay/tmp/ oder /tmp/, je nach Setup, z. B. /Applications/ServBay/tmp/mysql.sock oder /tmp/mysql.sock.
ServBay-Standardeinstellungen:
- In den ServBay-Einstellungen unter „Standard-SQL-Server“ die korrekte MariaDB/MySQL-Version wählen. Diverse Clients (z. B. das mysql-CLI ohne Angabe von -S oder -h) greifen auf den Default-Socket zu.
Berechtigungsprobleme:
- macOS: Die Nutzerrechte für das Verzeichnis des Socket-Files und die Datei selbst müssen passen. ServBay setzt die Rechte korrekt, falls Sie aber /Applications/ServBay/tmp/ oder /tmp/ manuell angepasst haben, gibt es evtl. Fehler.
- Windows: Prüfen Sie, ob Ihr Nutzerkonto die nötigen Rechte zum Öffnen von Named Pipes oder TCP/IP besitzt.

Alternative (Explizite Netzverbindung erzwingen):

Verbinden Sie sich explizit über die IP 127.0.0.1 statt „localhost“ – so nutzt der Client garantiert TCP/IP statt Unix-Socket. Gelingt dies, liegt das Problem ziemlich sicher am Socket.
bash
```
mysql -u <username> -p -h 127.0.0.1 -P 3306
```
1

2. Verbindungsfehler: Netzwerkprobleme (`Connection refused`, `Can't connect to MySQL server` etc.)

Hier kann der Client keinen TCP/IP-Zugang auf die Datenbank öffnen.

Mögliche Ursachen und Lösungen:

MariaDB/MySQL läuft nicht: (Vergleiche Variante oben – Status prüfen und .err ansehen!)
Port besetzt:
- Der gewünschte Datenbankport (Standard: 3306) wird ggf. von einer anderen Anwendung belegt.
macOS:
bash
```
lsof -i :3306
# Oder:
netstat -anv | grep LISTEN | grep 3306
```
1
2
3
Windows:
cmd
```
netstat -an | findstr :3306
# Oder mit PowerShell:
Get-NetTCPConnection -LocalPort 3306
```
1
2
3
Ist der Port belegt, muss die belegende Anwendung beendet, oder der port-Parameter in my.cnf geändert und die Datenbank neu gestartet werden.
- macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

Firewall blockiert Verbindung:

macOS:

Prüfen Sie die Netzwerkeinstellungen und die Firewall unter den macOS-Systemeinstellungen.

Sie können temporär den mysqld-Prozess explizit erlauben:

bash

# Beispiel, Pfad ggf. anpassen!
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:

Windows Defender Firewall oder Drittanbieter-Tools prüfen.

Ausnahme-Regel hinzufügen:

cmd

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

Konfigurationsfehler (bind-address):
- Prüfen Sie in der my.cnf, welcher Wert für bind-address gesetzt ist. Steht dort 127.0.0.1 oder localhost, sind ausschließlich lokale TCP/IP-Verbindungen möglich. Für Verbindungen von anderen Rechnern/VMS 0.0.0.0 oder spezifische IP setzen und Firewall prüfen.
Hostnamen-Auflösung (localhost):
- Sicherstellen, dass „localhost“ korrekt auf 127.0.0.1 (IPv4) oder ::1 (IPv6) auflöst.
macOS:
bash
```
ping localhost
# Hosts-Datei prüfen
cat /etc/hosts
```
1
2
3
Windows:
cmd
```
ping localhost
# Hosts-Datei prüfen
type C:\Windows\System32\drivers\etc\hosts
```
1
2
3
Stellen Sie korrekte Hosts-Einträge sicher. Ein Proxy-Server kann den lokalen Verkehr stören.

3. MariaDB/MySQL startet nicht

Mögliche Ursachen und Lösungen:

Fehlerprotokoll prüfen: (Meist entscheidend!) Siehe vorherigen Abschnitt.
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err

Fehlerhafte Konfigurationsdatei:

Dateipfad:

macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

Syntax überprüfen:

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

Port besetzt: (Siehe oben – per lsof -i :<port> oder netstat prüfen)
Kein Speicherplatz: Insbesondere im Daten- oder Log-Verzeichnis.
Pfadübersicht:
- macOS: Datenverzeichnis /Applications/ServBay/db/mariadb/<version>/, Log-Verzeichnis /Applications/ServBay/logs/mariadb/<version>/
- Windows: Datenverzeichnis C:\ServBay\db\mariadb\<version>\, Log-Verzeichnis C:\ServBay\logs\mariadb\<version>\
Berechtigungsprobleme: Prüfen Sie Datei- und Ordnerrechte.
macOS:
bash
```
ls -ld /Applications/ServBay/db/mariadb/<version>
ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
ls -ld /Applications/ServBay/logs/mariadb/<version>
```
1
2
3
Der Prozessnutzer (z. B. _mysql) muss für Lesen/Schreiben/Starten berechtigt sein.
Windows: Pfadeigenschaften im Explorer prüfen – das ServBay-Servicekonto benötigt ausreichend Rechte.
Beschädigte Datenbankdateien: (Siehe Abschnitt „Crash/Datenverlust“ unten) Nach einem unsauberen Shutdown können sich Defekte einschleichen.

Lösung nach Fehlerbehebung:

Datenbankpaket (neu) starten: servbayctl restart mariadb <version>

4. Benutzerrechte und Authentifizierungsprobleme

Nach erfolgreicher Verbindung können Authentifizierungsfehler wie Access denied auftreten – oft ein Rechteproblem.

Mögliche Ursachen und Lösungen:

Falscher Benutzername oder Passwort: Vergewissern Sie sich, dass Sie mit korrekten Credentials anmelden. ServBay ermöglicht das Zurücksetzen des root-Passworts.
Host-Einschränkung: Nutzer sind auf bestimmte Hosts limitiert (z. B. '<username>'@'localhost'). '<username>'@'127.0.0.1' kann dann fehlschlagen, und umgekehrt. Das Zeichen % steht für beliebige Hosts.
Mangelnde Rechte: Möglicherweise fehlen Zugriffsrechte für bestimmte Datenbanken oder Operationen (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP usw.).

Prüfung per SQL:

Melden Sie sich mit root oder einem berechtigten Account an:
bash
```
mysql -u root -p
```
1

Berechtigungen eines Users prüfen:

sql

SHOW GRANTS FOR '<username>'@'<hostname>';
-- Beispiel: Rechte von 'webapp'@'localhost':
SHOW GRANTS FOR 'webapp'@'localhost';
-- Beispiel: Rechte von 'admin'@'%':
SHOW GRANTS FOR 'admin'@'%';

Rechte können mit GRANT und REVOKE angepasst oder neue Nutzer angelegt werden.

5. Performance-Probleme

Sinkende Datenbank-Performance betrifft oft die gesamte Webanwendung.

Mögliche Ursachen und Lösungen:

Langsame SQL-Abfragen: Mangelnde Indexierung oder ineffiziente Syntax.
- Slow-Query-Log einschalten: In my.cnf slow_query_log = 1 und z. B. long_query_time = 1 konfigurieren, Logfile-Pfad mit slow_query_log_file bestimmen. Nach dem Neustart Auswertung des Logs, um die „Slow Queries“ zu finden.
- Mit EXPLAIN analysieren: EXPLAIN vor langsame oder auffällige Abfragen stellen, um Indexverwendung und Scan-Volumen zu sehen.
  sql
```
EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
```
  1
- Abfragen optimieren: Vermeiden Sie ineffiziente Konstrukte und stellen Sie sicher, dass WHERE/JOIN-Klauseln Indexnutzung erlauben.
Fehlende oder falsche Indizes: Ohne passende Indexe wird die gesamte Tabelle durchsucht.
- Tabellenstruktur analysieren und Indexe auf Feldern erstellen, die häufig gefiltert, sortiert oder gruppiert werden.
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  Achtung: Indexe kosten Schreibperformance und Speicher!
Ungeeignete Cache-Einstellungen: Parameter wie innodb_buffer_pool_size und key_buffer_size in my.cnf sollten an Hardware und Nutzung angepasst werden.
- Konfiguration anpassen: Für Datenbankserver ist typischerweise ein Anteil von 50–70% des verfügbaren RAM für innodb_buffer_pool_size sinnvoll.
  ini
```
[mysqld]
# Anpassen, nach Bedarf – Einheiten: K, M, G etc.
innodb_buffer_pool_size = 2G
# Bei Nutzung von MyISAM:
# key_buffer_size = 256M
```
  1
  2
  3
  4
  5
Hardware-Limitierung: Hohe CPU-Auslastung, zu wenig RAM, langsame Platte. Nutzen Sie den Aktivitätenmonitor (macOS) oder top/htop, um Engpässe zu lokalisieren.

6. Crash oder Datenverlust

Startfehler, regelmäßige Abstürze oder Inkonsistenzen deuten meist auf beschädigte Datenbankdateien hin.

Mögliche Ursachen und Lösungen:

Error-Log lesen: Zeigt den genauen Fehler an – für alle Crashs essenziell.
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err
Hardwarefehler: Festplatten- oder RAM-Defekte können zu Dateischäden führen. Prüfen Sie System-Logs und führen Sie Hardwaretests durch.
Software-Bugs oder -Konflikte: Bestimmte MariaDB/MySQL-Versionen oder Drittsoftware können Inkonsistenzen hervorrufen.
Konfigurationsfehler: Ungültige Einstellungen in my.cnf verursachen manchmal Instabilität und Abstürze.
Unsanfter Shutdown (Prozess-Killer, Stromausfall): Daten- oder Logdateien werden nicht sauber geschrieben und können inkonsistent sein.

Empfohlene Vorgehensweise:

Sanftes Neustarten versuchen: Über ServBay oder per CLI: servbayctl restart mariadb <version>. Manchmal läuft die DB einen Selbstheilungsprozess.

Mit mysqlcheck Tabellen prüfen/reparieren: Funktioniert primär mit MyISAM.

bash

# Mit ServBay-Konfig + root prüfen:
mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
# Automatische Reparatur bei MyISAM:
# mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

Hinweis: --auto-repair hilft nur bei MyISAM! Für InnoDB siehe unten.

InnoDB Forced Recovery (innodb_force_recovery): Bei schweren Fehlern im InnoDB-Modul, kann dieser Notmodus helfen, um Daten zu retten – hohes Risiko, Gefahr von Datenverlust!
1. Machen Sie zunächst eine Kopie des Datenverzeichnisses, z. B. /Applications/ServBay/db/mariadb/<version>/.
2. Konfigurationsdatei öffnen und unter [mysqld] einfügen: innodb_force_recovery = N (N=1–6; steigern Sie schrittweise).
3. Datenbank starten: servbayctl start mariadb <version>.
4. Falls erfolgreich, sofort vollständigen Dump erstellen:
  bash
```
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
  Prüfen Sie die Größe und den Inhalt des Backups!
5. Datenbank stoppen: servbayctl stop mariadb <version>.
6. Entfernen/kommentieren Sie innodb_force_recovery aus der Konfiguration.
7. Recovery: Neues Datenverzeichnis aufsetzen, Backup importieren.

Wiederherstellung aus Backup: Bei irreparablen Schäden Datenbank aus letztem, funktionalen Backup wiederherstellen. ServBay-Backups liegen typischerweise unter /Applications/ServBay/backup/mariadb/<version>/.

Beispiel für Import in eine Zieldatenbank:

bash

# Datenbank vorher anlegen:
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Einspielen des Backups:
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Hinweis: <version> ersetzen!

7. Probleme mit Backup und Wiederherstellung

Fehler können sowohl bei ServBay-internen Backups als auch bei manuellen mysqldump-Backups/Wiederherstellungen auftreten.

Mögliche Ursachen und Lösungen:

Unvollständige oder beschädigte Backup-Datei:
- Größe prüfen (ls -lh /path/to/your_backup.sql), Inhalt mit Editor oder less ansehen.
- Fehler während einer mysqldump-Sicherung oder im ServBay-Backup-Log kontrollieren.
Fehlerhafte Import-Kommandos:
- Falsche Nutzer, Passwort, Zieldatenbank oder mangelnde Rechte.
- Syntaxfehler (bei Restore zwischen verschiedenen DB-Engines oder Versionen).
Fremdschlüsselproblematik: Die Reihenfolge des Imports kann zu Fehlermeldungen führen, etwa wenn abhängige Tabellen fehlen. Temporär abschalten:
sql
```
-- Vor Import
SET foreign_key_checks = 0;
-- Import durchführen:
source /path/to/your_backup.sql; -- im mysql-Client
-- Oder via CLI: mysql ... < /path/to/your_backup.sql

-- Nach dem Import
SET foreign_key_checks = 1;
```
1
2
3
4
5
6
7
8
Achtung: Missbrauch kann Inkonsistenzen erzeugen – nur für den Import verwenden!
Zeichensatz/Kollationsprobleme: Unterschiedliche Zeichensätze zwischen Quell-Backup und Ziel-DB können Fehler oder Zeichensalat verursachen. Achten Sie auf Konsistenz, z. B. utf8mb4.

Empfohlene Wiederherstellung (CLI-Beispiel):

macOS:

bash

# Backup für spezifische Datenbank:
# Datenbank vorab anlegen:
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Restore
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# Backup enthält alle Datenbanken (--all-databases)? Dann kein DB-Name nötig!
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Windows:

cmd

REM Backup für spezifische Datenbank:
REM Datenbank vorab anlegen:
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 Restore
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 Backup enthält alle Datenbanken? Kein DB-Name nötig!
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>

Hinweis: <version> stets anpassen. ServBay-Backups sind üblicherweise kompatibel für den Restore und die Oberfläche führt Sie durch die Schritte.

8. Spezieller Bug: MariaDB 11.5.1 InnoDB startet nicht (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)

Ein bekannter schwerer Fehler in MariaDB 11.5.1 betrifft die InnoDB-Engine – sie kann nicht initialisiert werden, wenn die Logdatei fehlt oder inkonsistent ist.

Beispiele für Fehlermeldungen:

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

Oder:

[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

Das zeigt, dass InnoDB ihre Logdateien nicht finden oder auswerten kann und damit nicht startet.

Lösung (inkl. Datenmigration – Backup unbedingt zuerst versuchen!):

Es handelt sich um einen schwerwiegenden Bug, der sich mit Standardmethoden kaum beheben lässt. Die beste Option: Start erzwingen, Backup erstellen, auf eine stabile Version migrieren.

Erzwinge Recovery für Datenrettung (Risiko!):

Konfiguration bearbeiten:

macOS: /Applications/ServBay/etc/mariadb/11.5/my.cnf
Windows: C:\ServBay\etc\mariadb\11.5\my.cnf

In [mysqld] eintragen: innodb_force_recovery = 6

Dienst starten:

bash

servbayctl start mariadb 11.5

Backup sofort erstellen:

macOS:

bash

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:

cmd

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

Sicherstellen, dass das Backup inhaltlich und von der Größe her plausibel ist!

Problemversion stoppen und Datenverzeichnis behandeln:
- Dienst stoppen: servbayctl stop mariadb 11.5
- In my.cnf die Zeile innodb_force_recovery entfernen oder auskommentieren

ServBay MariaDB/MySQL Fehlerbehebungsleitfaden ​

Überblick ​

Allgemeine Schritte zur ersten Problemdiagnose ​

Häufige Probleme und Lösungswege ​

1. Verbindungsfehler: SQLSTATE[HY000] [2002] No such file or directory ​

2. Verbindungsfehler: Netzwerkprobleme (Connection refused, Can't connect to MySQL server etc.) ​

3. MariaDB/MySQL startet nicht ​

4. Benutzerrechte und Authentifizierungsprobleme ​

5. Performance-Probleme ​

6. Crash oder Datenverlust ​

7. Probleme mit Backup und Wiederherstellung ​

8. Spezieller Bug: MariaDB 11.5.1 InnoDB startet nicht (ib_logfile0 was not found / Missing FILE_CHECKPOINT) ​

ServBay MariaDB/MySQL Fehlerbehebungsleitfaden

Überblick

Allgemeine Schritte zur ersten Problemdiagnose

Häufige Probleme und Lösungswege

1. Verbindungsfehler: `SQLSTATE[HY000] [2002] No such file or directory`

2. Verbindungsfehler: Netzwerkprobleme (`Connection refused`, `Can't connect to MySQL server` etc.)

3. MariaDB/MySQL startet nicht

4. Benutzerrechte und Authentifizierungsprobleme

5. Performance-Probleme

6. Crash oder Datenverlust

7. Probleme mit Backup und Wiederherstellung

8. Spezieller Bug: MariaDB 11.5.1 InnoDB startet nicht (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)