
所以......昨天我收到了一封“事後電子郵件”,內容涉及我運行的一項服務已開始的活動。現在,資料庫伺服器正在遭受重創,複製的二進位日誌記錄速度約為 300mb/min。正如你可以想像的那樣,這正在以相當驚人的速度吞噬空間。
我的二進位日誌通常有 7 天的有效期,但並沒有縮短它的時間。我已經採取了將日誌截斷到最後 4 小時的方法(我正在驗證複製是否是最新的mk-heartbeat
):
PURGE MASTER LOGS BEFORE DATE_SUB( NOW(), INTERVAL 4 HOUR);
我只是每隔幾個小時從 cron 運行一次以度過難關,但這讓我質疑 的最小值expire_logs_days
。我還沒有遇到小於 1 的值,但這並不意味著它不可能。http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_expire_logs_days給出數字類型,但不指示它是否需要整數。
答案1
其實,有一種方法可以模仿。
以下是將二進位日誌清除到 1 小時的步驟。
步驟 01) 建立一個 SQL 腳本,該腳本將刪除時間戳記早於一小時的所有二進位日誌:
echo "FLUSH LOGS;" > /usr/bin/purge.sql
echo "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 HOUR;" >> /usr/bin/purge.sql
步驟 02) 建立一個 shell 腳本 ( /usr/bin/purge.sh
) 來mysql
調用purge.sql
mysql -uroot -p... < /usr/bin/purge.sql
步驟 03) 使/usr/bin/purge.sh
可執行文件
chmod +x /usr/bin/purge.sh
步驟 04) 加入usr/bin/purge.sh
crontab 以每小時開始一次
0 * * * * /usr/bin/purge.sh
試一試 !
答案2
實驗是當晚的當務之急...
mysql> 設定@@global.expire_logs_days=0.75; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=.75; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=3.4; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=3/4; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=F; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=0xF; 錯誤 1232 (42000):變數「expire_logs_days」的參數類型不正確 mysql> 設定@@global.expire_logs_days=1; 查詢正常,0 行受影響(0.00 秒)
答案3
該頁面確實說範圍是 0-99.. 所以是的,它是一個整數。
0 = 沒有過期..
你讓我想知道 0.5 會做什麼..我想它會忽略 .5 部分並且不會使它們過期..
答案4
Mysql(社群)版本 8.0.17-1.sles12 - OpenSUSE tumbleweed 2019.10.02
mysql> SET GLOBAL expire_logs_days = 4;
ERROR 3683 (HY000): The option expire_logs_days and binlog_expire_logs_seconds
cannot be used together. Please use binlog_expire_logs_seconds to set the expire
time (expire_logs_days is deprecated)
..
SET PERSIST binlog_expire_logs_seconds = 86400;
我添加了這個 my.cnf 文件
[mysqld]
binlog_expire_logs_seconds = 86400
expire_logs_days = 1