MySQL schreibt verrückte Fehlerprotokolle

Eine Kerngeschäftsdatenbank, die Version ist MySQL 8.34
Community Server Edition. Seit seiner Einführung ist das Fehlerprotokoll dieses Datenbankservers sehr schnell gestiegen (wie in der Abbildung unten dargestellt) und erreicht alle 24 Stunden eine Kapazität von mehr als 10 G
.

Da ein Fehleralarm vorliegt und dieser den normalen Zugriff auf das Unternehmen nicht beeinträchtigt hat, ist es dem zuständigen Personal nicht gestattet, den MySQL

-Dienst neu zu starten. Angesichts dieser Situation musste ich eine automatische geplante Aufgabe einrichten, um diese Protokolle jede Nacht zu einer festen Zeit zu bereinigen. Führen Sie für bestimmte Vorgänge „crontab -e“

in der Systembefehlszeile aus und fügen Sie die folgende Textzeile hinzu:

00 01 * * * echo > /data/mysql8/data/mysql_db/mysql.logSpeichern und beenden Sie den Bearbeitungsmodus. Wenn Sie die Richtigkeit und Gültigkeit der Aufgabe überprüfen müssen, können Sie die Ausführungszeit auf einen relativ aktuellen Zeitpunkt ändern und dann die Fehlerprotokolldatei „mysql.log

“ vorher und nachher vergleichen Überprüfen Sie die Größe der Aufgabenausführung und überprüfen Sie das Cron-Protokoll, um festzustellen, ob diese geplante Aufgabe ausgeführt wurde, wie in der Abbildung unten dargestellt.

Es ist Frühlingsfest, alle gehen nach Hause, um das neue Jahr zu feiern, und dies ist die niedrigste Zeit für Besuche. Ich möchte diese Gelegenheit nutzen und dieses Problem vollständig lösen. Holen Sie Meinungen von relevanten Mitarbeitern ein und fragen Sie, ob es möglich ist, die MySQL-Optionsdatei zu ändern, um nutzlose Warnausgaben zu blockieren? Die Antwort war „

Wie lange dauert der Neustart“

? Die Antwort: „

Ein paar Minuten reichen“
.



Was zeichnet dieses definierte Fehlerprotokoll in großen Mengen auf? Öffnen Sie die große Datei „mysql.log“ und stellen Sie fest, dass sie voller Warnmeldungen ist. Die Bildschirmausgabe rollt wie ein Motorschwungrad Abbildung unten.

Diese Warnmeldungen weisen darauf hin, dass das Benutzerkonto „mysql_native_password“

verwendet, was nicht mit der Standardauthentifizierungsmethode „
caching_sha2_password“
übereinstimmt. Die Lösung besteht darin, entweder die Passwortauthentifizierungsmethode aller Benutzerkonten in „

caching_sha2_password“ zu ändern oder die Fehlerprotokolldatei „mysql.log“

diese Warnmeldungen nicht aufzuzeichnen. Da es viele Benutzerkonten gibt und mehrere Unternehmen konzipiert sind, ist es einfacher, Warnmeldungen nicht aufzuzeichnen (lassen Sie sie echte Fehlerprotokolle aufzeichnen, was bei der Fehlerbehebung hilfreich ist).



MySQL
Das Hostsystem Centos 7, auf dem sich der Server befindet,
Öffnen Sie die Optionsdatei „/etc/my.cnf“

im Texteditor und hängen Sie die folgenden Textzeilen im Textblock [mysqld

] an.

log-error-verbosity=1

Standardmäßig ist der Wert von „log-error-verbosity“ von MySQL 8 „3“

, was bedeutet, dass alle „

Fehler, Warnungen und Kommentare“

im Fehlerprotokoll aufgezeichnet werden. Die Zahl „2

“ bedeutet die Protokollierung von „Fehlern und Warnungen“, während die Zahl „1
“ bedeutet, dass nur „Fehler“ protokolliert werden.




Beachten Sie, dass Sie vor dem Ändern der Optionsdatei zunächst eine Sicherungskopie der Datei erstellen müssen. Dies ist gesunder Menschenverstand und ein Mittel gegen Bedauern. Nachdem Sie überprüft haben, dass keine Schreibfehler vorliegen, starten Sie den MySQL-Dienst neu und prüfen Sie dann, ob der lokale MySQL-Dienst normal ist, ob die Remote-Master-Slave-Synchronisierung normal ist und ob es zu Verzögerungen kommt.

Überprüfen Sie nach einigen Minuten Ausführung das Fehlerprotokoll von MySQL

, um festzustellen, ob es nicht mehr schnell wächst. Nach längerer Beobachtung stimmt es tatsächlich, dass MySQL-Warnprotokolle nicht mehr aufgezeichnet werden und auch die Dateiwachstumsrate stark zurückgegangen ist.

Das obige ist der detaillierte Inhalt vonMySQL schreibt verrückte Fehlerprotokolle. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!