mysql 清除relay

本文章來給大家介紹在mysql 清除relay-log文件與relay-log無法清除的解決辦法，這裡同時還介紹了系統自動定時清除relay-log文件哦。

今天在本機的mysql數據目錄下發現了許多類似hostname-relay-bin.0000*的文件，該文件一般是在mysql slave實例上存在。主要用途是記錄主從同步的信息，正常情況下會自動刪除的。

本機未配置過master、slave，對於其來源還真不太清楚。既然是用在slave上的，那就可以放心的刪除。刪除master實例上的日志文件用reset master，對於slave實例就使用命令:

 代碼如下 復制代碼

reset 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