本博客已經遷移至：
http://cenalulu.github.io/
本篇博文已經遷移，閱讀完整的文章請點擊：
http://cenalulu.github.io/mysql/cannot-rotate-relaylog/
今天在運維一個mysql實例時，發現其數據目錄下的relay-log 長期沒有刪除，已經堆積了幾十個relay-log。
然而其他作為Slave服務器實例卻沒有這種情況。
綜合分析后發現和以下原因有關。
然而其他作為Slave服務器實例卻沒有這種情況。
綜合分析后發現和以下原因有關。
- 該實例原先是一個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機制：
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堆積的情況。