關於Relay Log無法自動刪除的問題

本文介紹了一次營運實踐中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堆積的情況。

--本篇文章轉自：http://cenalulu.github.io/mysql/cannot-rotate-relaylog/

我個人情況是：relay_log_purge 參數值為ON，但是relay log卻積累了好多。SQL進程停止：

 Slave_IO_Running: Yes
     Slave_SQL_Running: No

原因是主從資料不一致，從庫存在某條資料，主庫insert該記錄時，在從庫執行就報錯了。

我把主從不一致的問題處理完之後，start slave.第二天發現relay log自動清除了，只剩兩個了。

看來slave的兩個進程是否正常還影響到relay log是否能自動清除啊。