
Entonces... ayer recibí un "correo electrónico posterior al hecho" sobre una campaña que comenzó para uno de los servicios que administro. Ahora el servidor de base de datos está siendo golpeado con fuerza, a una velocidad de aproximadamente 300 MB/min en el registro binario para la réplica. Como se puede imaginar, esto está consumiendo espacio a un ritmo tremendo.
Mi vencimiento normal de 7 días de registros binarios simplemente no es suficiente. He recurrido a truncar registros solo al último durante 4 horas con (estoy verificando que la replicación esté actualizada con mk-heartbeat
):
PURGE MASTER LOGS BEFORE DATE_SUB( NOW(), INTERVAL 4 HOUR);
Simplemente estoy ejecutando eso desde cron cada pocas horas para capear la tormenta, pero me hizo cuestionar el valor mínimo de expire_logs_days
. No he encontrado un valor menor que 1, pero eso no significa que no sea posible.http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_expire_logs_daysproporciona el tipo como numérico, pero no indica si espera números enteros.
Respuesta1
De hecho, hay una manera de emularlo.
Estos son los pasos para purgar los registros binarios a 1 hora.
PASO 01) Cree un script SQL que eliminará todos los registros binarios cuya marca de tiempo tenga más de una hora:
echo "FLUSH LOGS;" > /usr/bin/purge.sql
echo "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 1 HOUR;" >> /usr/bin/purge.sql
PASO 02) Cree un script de shell ( /usr/bin/purge.sh
) para mysql
llamarpurge.sql
mysql -uroot -p... < /usr/bin/purge.sql
PASO 03) Hacer /usr/bin/purge.sh
ejecutable
chmod +x /usr/bin/purge.sh
PASO 04) Agregar usr/bin/purge.sh
al crontab para iniciar cada hora
0 * * * * /usr/bin/purge.sh
Darle una oportunidad !!!
Respuesta2
Experimentar estuvo a la orden de la noche...
mysql> establecer @@global.expire_logs_days=0.75; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=.75; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=3.4; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=3/4; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=F; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=0xF; ERROR 1232 (42000): tipo de argumento incorrecto para la variable 'expire_logs_days' mysql> establecer @@global.expire_logs_days=1; Consulta correcta, 0 filas afectadas (0,00 s)
Respuesta3
Esa página dice que el rango es 0-99... así que sí, es un número entero.
0 = Sin caducidad..
Me haces preguntar qué haría 0.5. Estoy pensando que ignoraría la parte .5 y simplemente no la expiraría.
Respuesta4
Mysql (comunidad) Versión 8.0.17-1.sles12 - Planta rodadora 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)
..
SET PERSIST binlog_expire_logs_seconds = 86400;
Agregué este archivo my.cnf
[mysqld]
binlog_expire_logs_seconds = 86400
expire_logs_days = 1