清除二進制日誌需要時間
我們觀察到一些查詢的高延遲,進一步探勘我們發現每 5 分鐘查詢一次通過檢查慢查詢日誌需要很長時間。
我們觀察到
PURGE BINARY LOGS TO 'mysql-bin-changelog.041045';
每 5 分鐘執行一次,耗時超過 1000 毫秒。同時查詢如
SET timestamp=1492673425; commit;
也需要時間和
SELECT @@session.tx_isolation;
我們在 Amazon RDS 上使用 MySQL 5.7.11。為什麼
PURGE BINARY LOGS
會花費更長的時間並導致其他查詢也同時卡住?
這是我 2 個月前在 RDS 之外經歷過的 MySQL 5.7 中一個相當討厭的錯誤。有一種奇怪的互斥行為涉及清除二進制日誌的行為。
我的解決方法是手動刪除 bin-log.index 中列出的作業系統中的一些二進制日誌並執行
PURGE BINARY LOGS BEFORE CURDATE() + INTERVAL 2 HOUR;
(每凌晨 2 點清除一次)。它加快了速度,因為它在作業系統中檢查的文件更少。當涉及到仍然存在的實際 binlog 時,執行PURGE BINARY LOGS ...
只是被拖了。這就是為什麼我做了手動煙霧和鏡子的東西。您的實際情況
在您的特定實例中,您使用的是 RDS。由於您無法進入作業系統,因此您無法對 binlogs 執行任何其他操作,因為無法在 RDS 參數組中更改max_binlog_size 。如果您有大量或許多事務需要在寫入二進制日誌之前記憶體,您可以更改max_binlog_cache_size,但這可能會或可能不會有幫助,具體取決於您在應用程序中寫入的頻率。
推薦
MySQL 5.6 中不存在此問題。
您可能必須將數據庫遷移回 MySQL 5.6.27 RDS。
結語
根據我的經驗,我是 MySQL 5.7.12 中這個 bug 的受害者。您告訴我該錯誤已在 MySQL 5.7.14 中得到解決。我希望我已經像我想要的那樣升級了。由於您的情況出現在 MySQL 5.7.11 上,我知道除了我之外的其他人注意到了這個問題。盡快升級到 5.7.16。祝你有美好的一天 !!!