本文介紹了一次運維實踐中relay-log長期無法自動刪除的原因和解決過程

背景： 今天在運維一個mysql例項時，發現其資料目錄下的relay-log 長期沒有刪除，已經堆積了幾十個relay-log。 然而其他作為Slave伺服器例項卻沒有這種情況。

現象分析

通過收集到的資訊，綜合分析後發現relay-log無法自動刪除和以下原因有關。

• 該例項原先是一個Slave:導致relay-log 和 relay-log.index的存在
• 該例項目前已經不是Slave:由於沒有了IO-Thread，導致relay-log-purge 沒有起作用（ 這也是其他Slave例項沒有這種情況的原因，因為IO-thread會做自動rotate操作）。
• 該例項每天會進行日常備份:Flush logs的存在，導致每天會生成一個relay-log
• 該例項沒有配置expire-logs-days:導致flush logs時，也不會做relay-log清除

簡而言之就是： 一個例項如果之前是Slave，而之後停用了（stop slave），且沒有配置expire-logs-days的情況下，會出現relay-log堆積的情況。

深入分析

順帶也和大家分享下MySQL 內部Logrotate的機制

Binary Log rotate機制：

• Rotate：每一條binary log寫入完成後，都會判斷當前檔案是否超過 max_binlog_size
  ，如果超過則自動生成一個binlog file
• Delete：expire-logs-days 只在 例項啟動時 和 flush logs 時判斷，如果檔案訪問時間早於設定值，則purge file

Relay Log rotate 機制：

• Rotate：每從Master fetch一個events後，判斷當前檔案是否超過 max_relay_log_size 如果超過則自動生成一個新的relay-log-file
• Delete：purge-relay-log 在SQL Thread每執行完一個events時判斷，如果該relay-log 已經不再需要則自動刪除
• Delete：expire-logs-days
  只在 例項啟動時 和 flush logs 時判斷，如果檔案訪問時間早於設定值，則purge file （同Binlog file） (updated: expire-logs-days和relaylog的purge沒有關係) PS： 因此還是建議配置 expire-logs-days ， 否則當我們的外部指令碼因意外而停止時，還能有一層保障。

因此建議當slave不再使用時，通過reset slave來取消relaylog，以免出現relay-log堆積的情況。