MySQL 狂寫錯誤日誌

一臺核心業務數據庫，版本爲MySQL 8.34社區服務器版。從上線以來，這個數據庫服務器的錯誤日誌增增加非常迅猛（如下圖所示），每24小時能增加到10多個G的容量。

 

因爲有故障報警，也還沒有影響到業務的正常訪問，有關人員不讓重啓MySQL服務。鑑於這個情況，我只好設置一個自動計劃任務，在每晚的夜間定點清理這些日誌。具體的操作時候在系統命令行，執行“crontab -e”，添加如下的文本行：

00 01 * * *    echo > /data/mysql8/data/mysql_db/mysql.log

保存並退出編輯模式，如果需要驗證任務的正確性和有效性，可以把執行時間修改到相當近的一個時間點，然後對比任務執行前與執行後，錯誤日誌文件“mysql.log”的大小，同時查看cron日誌是否執行了這個計劃任務，如下圖所示。

 

春節放假，所有的人都回家過年，並且這個時候是訪問低谷期，乘這個機會，我打算將這個問題徹底解決掉。徵詢相關人員的意見，問是否可以修改MySQL選項文件，屏蔽掉沒什麼用的警告輸出？得到的答覆是“重啓需要多久”？答曰：“數分鐘足夠”。

 

這個被定義的錯誤日誌，大量記錄的是什麼東西呢？打開”mysql.log”大文件，發現全是些警告信息，用系統命令“tail -f mysql.log”，屏幕輸出翻滾猶如電動機飛輪，具體的數據如下圖所示。

這些警告信息表示用戶賬號使用了與默認認證方式“caching_sha2_password”不一致的“mysql_native_password”。處理的方式要麼將所有的用戶賬號的密碼認證方式改成“caching_sha2_password”，要麼錯誤日誌文件“mysql.log”不記錄這些警告信息。由於用戶賬號比較多，設計到多個業務，相比之下，不記錄警告信息更容易一些，反正這些警告信息沒什麼用（讓它記錄真正的錯誤日誌，有助於排錯）。

 

MySQL服務器所在的宿主系統Centos 7,文本編輯器打開選項文件“/etc/my.cnf”，在文本塊【mysqld】裏追加如下文本行。

log-error-verbosity=1

 

默認情況下，MySQL 8的“log-error-verbosity”的值爲“3”，表示在錯誤日誌裏記錄所有的“錯誤、警告和註釋”。數字“2”代表記錄“錯誤和警告”，而數字“1”則代表僅記錄“錯誤”。

 

需要注意的是，在做選項文件修改前，記得先備份，這是常識，也是後悔藥。檢查沒有書寫錯誤以後，重啓MySQL服務，然後檢查本地MySQL服務是否正常，遠程主從同步是否正常及是否存在延遲。

 

運行幾分鐘以後，再查看MySQL的錯誤日誌，是否不再迅猛增長。通過一段時間觀察，確實不再記錄MySQL的警告日誌，文件的增長速度也大大的降下來了。

 

以上就是MySQL 狂寫錯誤日誌的詳細內容，更多請關注本站其它相關文章！