在 MySQL 中 expire_logs_days 可以少于 1 天吗？

Question

所以......昨天我收到了一封“事后电子邮件”，内容是关于我运行的一项服务已经开始的活动。现在，数据库服务器在二进制日志记录中受到重创，很难达到大约 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将类型指定为数字，但未指明它是否需要整数。

Answer 1

实验是晚上的顺序...

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> set @@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 秒）

Answer 2

实际上，有一种方法可以模仿它。

以下是将二进制日志清除到 1 小时的步骤。

步骤 01) 创建一个 SQL 脚本，该脚本将删除所有时间戳早于一个小时的二进制日志：

echo "FLUSH LOGS;" > /usr/bin/purge.sql
echo "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 HOUR;" >> /usr/bin/purge.sql

STEP 02）创建一个shell脚本（/usr/bin/purge.sh）调用mysql与purge.sql

mysql -uroot -p... < /usr/bin/purge.sql

STEP 03) 使/usr/bin/purge.sh可执行文件

chmod +x /usr/bin/purge.sh

STEP 04) 添加usr/bin/purge.sh到 crontab 以每小时启动一次

0 * * * * /usr/bin/purge.sh

试一试 ！！！

Answer 3

该页面确实说范围是 0-99.. 所以是的，它是一个整数。

0 = 没有过期..

你让我想知道 0.5 会做什么..我想它会忽略 .5 部分并且不会使它们过期..