Итак ... вчера я получил "постфактум по электронной почте" о кампании, которая началась для одной из служб, которые я запускаю. Теперь сервер БД сильно забивается примерно до 300 МБ / мин в двоичном журнале репликации. Как вы можете себе представить, это занимает место с огромной скоростью.
Мой обычный 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 дает тип как числовой, но не указывает, ожидает ли он целых чисел.
Вечер был в порядке экспериментов ...
mysql> set @@global.expire_logs_days=0.75; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=.75; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=3.4; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=3/4; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=F; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=0xF; ERROR 1232 (42000): Incorrect argument type to variable 'expire_logs_days' mysql> set @@global.expire_logs_days=1; Query OK, 0 rows affected (0.00 sec)
Собственно, есть способ подражать этому.
Вот шаги, чтобы очистить двоичные журналы до 1 часа.
ШАГ 01) Создайте сценарий SQL, который удалит все двоичные журналы, отметка времени которых старше часа:
echo "FLUSH LOGS;" > /usr/bin/purge.sql
echo "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 HOUR;" >> /usr/bin/purge.sql
ШАГ 02) Создайте сценарий оболочки (/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
Попробуйте !!!
На этой странице указан диапазон от 0 до 99 ... так что да, это целое число.
0 = Срок действия не истекает ..
Вы заставили меня задуматься, что будет делать 0,5 ... Я думаю, что он проигнорирует часть 0,5 и просто не истечет их срок действия ..
Mysql (сообщество) версии 8.0.17-1.sles12 - OpenSUSE перекати-поле 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)
..