Türkei (Türkisch)
Germany (German)
Worldwide (English)
Zuerst Daten-SicherheitDatenordner werden nicht gelöscht oder umbenannt.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wenn der MySQL- oder MariaDB-Dienst nicht läuft, kann WordPress, E-Commerce und alle dynamischen Websites auf die Datenbank zugreifen. Diese Anleitung diagnostiziert sicherheitsrelevante Dienst-, Speicher-, Berechtigungs-, Socket-, my.cnf-, InnoDB- und Aria-Fehler ohne Löschung der Datendateien.
The “mysql” service appears to be down.
Failed to start MariaDB database server.
InnoDB: Unable to lock ./ibdata1 error: 11
Can't connect to local server through socket '/var/lib/mysql/mysql.sock'Chkservd oder cPanel-Dienst-Manager MariaDB erkennt, wenn er nicht ausgeführt wird oder auf Gesundheitsprüfungen nicht reagiert. Manchmal ist der Dienst wirklich down; manchmal erscheint MariaDB aufgrund von Socket, Verbindung oder Überwachungsmethode down zu sein.
Der tatsächliche Grund für den Servicestartfehler ist normalerweise nicht die letzte Zeile im systemctl-Ausgabe, sondern der erste kritische Eintrag im MariaDB-Fehlerprotokoll. Das Protokoll sollte vom Anfang der Bootung aus gelesen und der erste Fehler gefunden werden.
Errcode 28, kein Speicherplatz auf Gerät oder fehlgeschlagene temporäre Dateienanlage weisen auf Diskplatz oder inode-Depletion hin. In diesem Fall sollte anstelle der MariaDB-Einstellung die Vollständigkeit des Dateisystems gelöst werden.
InnoDB-Korruption, Checksum-Mismatch oder Seitenkorruptionnachrichten deuten auf ein Risiko für die Datenintegrität hin. Die Dateien ibdata1, ib_logfile, redo log oder Tabelle sollten ohne Server-Backup nicht gelöscht werden.
Ein MySQL-Socket-Fehler bedeutet nicht immer, dass die Datenbank geschlossen ist. Der vom Client erwartete Socket-Pfad kann sich von dem von MariaDB erstellten Pfad unterscheiden oder ein alter PID/Socket-Datei bleibt übrig.
Die Diagnosebefehle auf dieser Seite ändern keine Datendateien. InnoDB-Force-Recovery-, Tabelle-Reparatur- und Datei-Übertragungsvorgänge sollten nur mit einem aktuellen Sicherungs- und Wiederherstellungsplan durchgeführt 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: cPanel-Health-Check konnte die MySQL/MariaDB-Dienst nicht bestätigen, dass er läuft.
Mögliche Ursache: Dienst ist geschlossen, antwortet nicht, Socket ist anders, Festplatte ist voll oder chkservd-Verbindung fehlgeschlagen.
Bedeutung: Der systemd-Startvorgang wurde nicht erfolgreich abgeschlossen.
Mögliche Ursache: my.cnf-Fehler, Berechtigung, Portkonflikt, Festplatte, InnoDB/Aria-Wiederherstellung oder beschädigtes Paket.
Bedeutung: cPanel restart-Script-Dienst hat nicht funktioniert und ist nicht hochgefahren; 2 Hauptursachen sind nicht.
Mögliche Ursache: Der tatsächliche Fehler befindet sich im Servicestart-Log.
Bedeutung: Das InnoDB-System-Tabellenspeicherfeld erscheint von einem anderen Prozess gesperrt zu sein.
Mögliche Ursache: Der zweite MariaDB-Prozess, für einen halbfertigen oder alten Prozess.
Bedeutung: InnoDB-Datenseitenintegritätsschaden erkannt.
Mögliche Ursache: Festplattenproblem, plötzlicher Stromausfall, Hardware-/RAM-Fehler oder korrupte Seite.
Bedeutung: Der Client konnte keine Verbindung zur erwarteten Unix-Socket-Datei herstellen.
Mögliche Ursache: Dienst ist nicht mehr verfügbar, Pfad zum Socket ist anders, Socket existiert nicht oder Rechtsschutzproblem.
Bedeutung: MariaDB kann temporäre oder dauerhafte Dateien nicht schreiben.
Mögliche Ursache: Festplattenplatz oder Inode 100%, /tmp ist voll oder Kontingentgrenze.
Bedeutung: Kann nicht auf das File in der MariaDB-Datennetzwerkverzeichnis zugreifen.
Mögliche Ursache: Falsche mysql:mysql-Besitzrechte, SELinux-Kontext, Berechtigungen oder Verderbnis nach Übertragung.
Bedeutung: Für die MariaDB-Version gibt es einen unbekannten Konfigurationsparameter.
Mögliche Ursache: Upgrade, Syntaxfehler oder alter MySQL-Parameter.
Bedeutung: Anzeigt, dass der von MariaDB zu hörende Port von einem anderen Prozess verwendet wird.
Mögliche Ursache: Zweites MySQL-Beispiel, Docker/Proxy oder falsche Dienstleistung.
Bedeutung: Der Aria-Speichermotor kann keine Protokolle öffnen oder abrufen.
Mögliche Ursache: Plötzliches Herunterfahren, Berechtigung, Festplattenvollständigkeit oder beschädigte Aria-Logs
Bedeutung: Die chkservd-Prüfung kann während des Datenbankprozesses möglicherweise keine Verbindung herstellen.
Mögliche Ursache: Socket-Pfad, Passwort/Health-Check, MySQL-Governor oder aufgrund eines hohen Lasts, Timeout.
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 -l --no-pager
/usr/local/cpanel/scripts/restartsrv_mysql --statusMariaDB- und cPanel-Dienstkontrolle zeigt die Situation gemeinsam.
journalctl -u mariadb -n 200 --no-pagerListet Fehler auf, die während des Starts und der Beendigung an systemd übergeben werden.
ls -lah /var/lib/mysql/*.err 2>/dev/null
tail -n 200 /var/lib/mysql/*.err 2>/dev/nullInnoDB, Aria, Berechtigungs- und Konfigurationsfehler sind die Hauptquelle.
my_print_defaults mysqld
mysqld --verbose --help 2>/dev/null | head -n 30Zeigt die geladenen my.cnf-Optionen und Binärinformationen an.
df -hT
df -ih
du -sh /var/lib/mysql /tmp 2>/dev/nullErrcode 28, temporäre Dateien und Schreibprobleme bestätigen die Dateisystemseite.
ss -lntp | grep ':3306'
ss -lxnp | grep -E 'mysql|maria'
find /run /var/lib/mysql -maxdepth 2 -type s -name '*mysql*.sock' -ls 2>/dev/nullZeigt an, ob MariaDB auf einem Port oder einem Unix-Socket lauscht.
ps auxf | grep -E '[m]ariadbd|[m]ysqld'
mysqladmin ping 2>&1
mysqladmin processlist 2>&1 | head -n 80Doppelprozess, Dienstantwort und gesteckte Abfragen überprüfen.
journalctl -k --since '2 hours ago' | grep -Ei 'oom|killed process|I/O error|ext4|xfs|nvme|sda'Bestimmt, ob MariaDB wegen OOM- oder Disk-I/O-Fehlern geschlossen wurde.
Validierung des Dienststatus, Suche nach dem ersten kritischen Log, Trennung des Dateisystems und der Konfiguration, sichere Neustart und Datenintegritätsprüfung.
Status, Journal und Fehlerprotokollausgabe erhalten. Häufige Neustarts können die erste Fehlerzeile in der Logrotation verlieren.
systemctl status mariadb -l --no-pager
journalctl -u mariadb -n 200 --no-pager
tail -n 200 /var/lib/mysql/*.errWenn Disk oder Inode voll ist, erstellen Sie zunächst einen sicheren Bereich. Bestimmen Sie, warum sich die Eigenalleerschaft und der SELinux-Kontext von /var/lib/mysql geändert haben.
df -hT
df -ih
namei -l /var/lib/mysqlWenn es unbekannte Variablen oder Syntaxfehler gibt, speichern Sie das File und korrigieren Sie nur den betroffenen Parameter. Die gesamte Konfiguration zurücksetzen kann die Leistungseinstellungen verlieren.
cp -av /etc/my.cnf /root/my.cnf.yedek-$(date +%F-%H%M)
my_print_defaults mysqldÜberprüfen Sie, welches PID 3306 verwendet und die Anzahl der aktiven mariadbd. Töten Sie den Produktionsprozess nicht zufällig.
ss -lntp | grep ':3306'
ps auxf | grep -E '[m]ariadbd|[m]ysqld'Nach Entfernen der Ursache verwenden Sie das cPanel-Service-Script und untersuchen Sie sofort die neuen Fehlerzeilen im Log.
/usr/local/cpanel/scripts/restartsrv_mysql
sleep 5
systemctl status mariadb -l --no-pagermysqladmin ping, eine einfache SQL-Anfrage, kritische Websites und neue Fehlerprotokolle müssen vor der Annahme der Operation als abgeschlossen überprüft werden.
mysqladmin ping
mysql -NBe 'SELECT VERSION(), NOW();'
tail -n 80 /var/lib/mysql/*.errAnstatt Datenbankdateien zu löschen, finden Sie den vollständigen Mount-Punkt. Log, Backup, /tmp und Binary-Log-Verwendung sollten separat untersucht werden.
df -hT
df -ih
du -xhd1 /var 2>/dev/null | sort -h | tail -n 20Im Allgemeinen läuft noch ein anderer mariadbd-Prozess. Löschung von ibdata1 oder pid-Datei ohne Verifizierung des PIDs und des Prozessbaums vermeiden.
ps auxf | grep -E '[m]ariadbd|[m]ysqld'
lsof /var/lib/mysql/ibdata1 2>/dev/nullZuerst nehmen Sie einen physischen oder Snapshot-Backup. innodb_force_recovery ist ein temporärer Wiederherstellungsmechanismus zum Ausführen von Datenexporten; es ist kein normaler Produktionsmodus.
grep -Ei 'corrupt|checksum|page.*error|crash' /var/lib/mysql/*.err | tail -n 100Während der TCP-Verbindung ist der Client auf dem falschen Socket-Pfad. Die Socket-Optionen in my.cnf sollten in beiden Client- und Server-Sektionen übereinstimmen.
my_print_defaults client mysql mysqld | grep -i socket
ss -lxnp | grep -E 'mysql|maria'Chkservd-Timeout kann aufgrund von Intensität auftreten. Prozessliste, Slow-Query-Log, Disk-Latenz und MySQL-Governor sollten gemeinsam untersucht werden.
mysqladmin processlist
mysqladmin status
iostat -xz 1 5cPanel meldet, dass es die Gesundheitsüberprüfung für MySQL/MariaDB nicht bestanden hat. Der Dienst könnte tatsächlich geschlossen sein oder aufgrund von Socket, Last und Überwachungsverfahren als geschlossen erscheinen.
Zuerst wird journalctl -u mariadb und die .err-Datei unter /var/lib/mysql untersucht. Die erste kritische Fehlerzeile zeigt normalerweise die Ursache.
Nein. ibdata1 ist ein InnoDB-System-Tabellenraum und seine Löschung kann zu schwerwiegenden Datenverlust führen; nur ein Experte sollte einen Recovery-Plan erstellen und einen Backup durchführen.
Wird normalerweise angezeigt, wenn der Festplattenspeicher oder die Inodes auslaufen. Der Mount-Punkt sollte mit df -h und df -i überprüft werden.
Zuerst überprüfen Sie, ob der Dienst läuft, wo der tatsächliche Socket ist, und den Pfad, den der Client erwartet. Die Client- und Server-Socket-Einstellungen sollten übereinstimmen.
Auf dem cPanel-Server wird der Befehl /usr/local/cpanel/scripts/restartsrv_mysql bevorzugt. Zuvor sollten die Logs abgerufen und danach der Error-Log erneut überprüft werden.
Nein. Es ist ein temporärer Recovery-Modus für die Datenexport; es ist keine dauerhafte Lösung für Schreibvorgänge und normale Produktion.
Chkservd kann keine Antwort über Socket oder Authentifizierung erhalten, der Dienst kann aufgrund hoher Last aus Zeit überschreiten oder die MySQL-Governor-Ebene kann sich auswirken.
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.