Türkei (Türkisch)
Germany (German)
Worldwide (English)
Zuerst Daten-SicherheitBackup und Log-Evidenz gesichert
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wenn MySQL oder MariaDB nicht verfügbar ist, können dynamische Websites und Datenbankvorgänge auf Plesk betroffen sein. Vollständige Festplatten, beschädigte mysql-Systemtabellen, InnoDB-Tabellenraum, falsche my.cnf, RAM- oder PID/Socketausgaben können ein Risiko für Datenverlust darstellen und sollten sorgfältig untersucht werden.
Failed to start MariaDB database server
Fatal error: Can't open and lock privilege tables
Table mysql.user doesn't exist
InnoDB: Cannot open tablespace
No space left on deviceEin nicht startender Dienst beweist nicht, dass die Datenbank beschädigt ist. Vollständige Festplatte oder inode, falsche Konfigurationsparameter, niedrige RAM, Portkonflikt und Systemtabellen können das gleiche Ergebnis erzeugen.
Kann keine Berechtigungstabellen öffnen oder mysql.user existiert nicht Meldungen zeigen an, dass die Systemdatenbanktabellen fehlen oder beschädigt sind. Sie sollten anders behandelt werden als Benutzerdatenbanken.
InnoDB-Tabellenspeicher- oder Seitengrößenmismatch-Fehler können eine Verderbnis eines bestimmten Kunden-Datenbanken anzeigt. innodb_force_recovery sollte nur für Datenablagezwecke und mit einem schrittweisen Wert verwendet werden.
No space left on device kann MariaDB daran hindern, temporäre Dateien, Redo-Logs oder PIDs zu schreiben. Das wiederholte Neustarten des Dienstes ohne vorherige Lösung des Disk- und Inode-Problems ist sinnlos.
Plesk repair db Plesk überprüft seine eigene psa-Datenbankkonsistenz; es ist ein allgemeiner Befehl, der alle Kunden-Datenbanken automatisch repariert.
ibdata1, ib_logfile, redo log oder Kunden .ibd-Dateien zu löschen kann irreparable Datenverlust verursachen, wie im Forum vorgeschlagen. Wenn der Service nicht startet, sollte zunächst die vollständige Datenverzeichniskopie und die Genauigkeit der bestehenden Sicherungen bewertet werden.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Die MariaDB-Berechtigungstabelle konnte nicht gefunden werden.
Mögliche Ursache: Unvollständige oder beschädigte mysql-Systemtabellen oder halbe Upgrade.
Bedeutung: Die Berechtigungstabelle konnte nicht geöffnet werden, daher konnte der Service nicht sicher gestartet werden.
Mögliche Ursache: Datei-Korruption, falsches Format, Berechtigungen oder fehlende Tabellen.
Bedeutung: InnoDB kann die angegebene Tablespace-Datei nicht öffnen.
Mögliche Ursache: Verlorenes .ibd, beschädigtes Metadaten, Festplatte oder falsche Dateiübertragung.
Bedeutung: MariaDB kann ein neues File oder temporäre Daten nicht schreiben.
Mögliche Ursache: Festplattenkapazität oder Inode ist zu 100% voll.
Bedeutung: Es gibt einen nicht unterstützten oder falsch geschriebenen Variablen in der MariaDB-Konfiguration.
Mögliche Ursache: Alte Parameter oder Tippfehler nach Versionserhöhung.
Bedeutung: Der Dienstprozess läuft, aber der Prüfunglskript kann die erwartete PID-Datei nicht finden.
Mögliche Ursache: Falscher Pfad für pid-Datei, alter Lock oder mehrere Diensteinheiten.
Bedeutung: Dienst ist abgeschlossen, aber das alte Lock-File bleibt bestehen.
Mögliche Ursache: OOM oder Shutdown fehlgeschlagen.
Bedeutung: MariaDB hat die Dateigröße des Betriebssystems erreicht.
Mögliche Ursache: Zu viele Tabellen/Verbindungen oder niedriger LimitNOFILE.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
systemctl status mariadb --no-pager 2>/dev/null || systemctl status mysql --no-pager 2>/dev/null || systemctl status mysqld --no-pagerZeigt den MySQL/MariaDB-Dienststatus basierend auf der Verteilung an.
journalctl -u mariadb -n 150 --no-pager 2>/dev/null
tail -n 150 /var/log/mariadb/mariadb.log 2>/dev/null || tail -n 150 /var/log/mysql/error.log 2>/dev/null || tail -n 150 /var/log/mysqld.log 2>/dev/nullZeigt den ersten technischen Grund für das anfängliche Versagen an.
df -hT
df -iZeigt den Speicherplatz-/Inode-Zustand in den Daten-, tmp- und Log-Partitionen an.
free -h
journalctl -k --since "2 hours ago" | grep -Ei "oom|out of memory|killed process"Zeigt an, ob MariaDB wegen Speicherdurchsatzes getötet wurde.
my_print_defaults mysqld 2>/dev/null
grep -RniE 'innodb_force_recovery|pid-file|datadir|socket' /etc/my.cnf /etc/my.cnf.d /etc/mysql 2>/dev/nullFindet aktive und riskante MariaDB-Konfigurationszeilen.
ss -lntp | grep :3306
ps -ef | grep -E "[m]ysqld|[m]ariadbd"Anzeigt Port 3306 und laufende reale Datenbankprozesse.
plesk repair dbPlesk überprüft die Datenbankkonsistenz interaktiv; es ist von der Kunden-DB-Reparatur unterschieden.
Bevor der Dienst gezwungen wird, sollten Log, Disk, RAM, Konfiguration und Datenintegrität nacheinander bewertet werden.
Die erste Fehlerzeile sollte mit der MariaDB/MySQL-Version vermerkt werden. Die letzte Zeile zeigt oft nur den fehlgeschlagenen Ergebnis.
Wenn kein Speicherplatz oder RAM vorhanden ist, muss die Systemressource vor der Datenbankreparatur sicher geöffnet werden.
df -hT && df -i && free -hNach der letzten Aktualisierung oder manueller Optimierung ermittelte nicht unterstützte Variablenzeilen.
mysql-Tabelle, Plesk psa-Datenbank und Kunden-Datenbank erfordern unterschiedliche Wiederherstellungsverfahren.
Innodb_force_recovery ist nicht der normalen Betriebsmodus für die Schreiboperation. Ein Backup-Plan wird mit dem niedrigsten Wert erstellt.
Nach dem Start des Services werden mysqlcheck/dump-Validierungen, Plesk DB-Prüfungen und Anwendungs-Tests durchgeführt.
Nach dem Öffnen des Bereichs werden Fehlerprotokoll, tmp-Verzeichnis, Redo-Protokoll und Dateisystemstatus überprüft; keine zufällige InnoDB-Datei wird gelöscht.
Paketversion, Systemtabelle-Aufwertung und alte my.cnf-Parameter werden überprüft.
Wenn der Service läuft, wird für die zugehörige DB eine tabellenbasierte Sicherung/Wiederherstellung durchgeführt; alle Daten bleiben unberührt.
Prozesse, die RAM verbrauchen, MariaDB Buffer-Einstellungen und systemd OOM-Logs werden analysiert.
Löschen Sie ohne Gewissheit, dass der echte mysqld-Prozess nicht existiert, PID oder Lock-Datei nicht.
Nein. Plesk konzentriert sich auf die Konsistenz der psa-Datenbank. Die Kunden-Datenbank und die InnoDB-Korruption sollten separat untersucht werden.
Für eine Notfall-Datenextraktion sollte es vom niedrigsten Wert aus starten und unter Expertenkontrolle erfolgen; es handelt sich nicht um ein normales Schreibmodus.
In einigen veralteten Sperrsituationen kann es vorübergehend lösen; aber es löst keine Disk-, korrupte Tabellen- oder my.cnf-Fehler und kann die Protokollevidenz reduzieren.
Ein teilweiser Upgrade, Dateikorruption, falsche Daten-Dir-Wiederherstellung oder Systemtabelle-Formatinkompatibilität kann dieses Problem verursachen.
Zuerst bestimmen Sie, welcher Mount voll ist und was den Speicher verbraucht. Datenbankdateien sollten nicht direkt gelöscht werden.
Die echte Anzahl der geöffneten Dateien, table_open_cache und systemd LimitNOFILE sollten gemeinsam gemessen und ausbalanciert werden.
Nein. Die Lesbarkeit von Tabellen, die Ausgabe von Dumps, die Anbindung an die Anwendung und die Persistenz nach einem Neustart sollten überprüft werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.