MySQL 狂寫錯誤日誌

sery發表於2024-02-14

一臺核心業務資料庫,版本為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 的警告日誌,檔案的增長速度也大大的降下來了。


來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/632405/viewspace-3006636/,如需轉載,請註明出處,否則將追究法律責任。

相關文章