Tengo MM Replication en mysql, y quiero exprimir un poco de espacio libre en la caja para eliminar archivos innecesarios, encontré estos mysql-binarchivos en el interior /var/db/mysql/Hay cientos de esos archivos mysql-bin.000123, mysql-bin.000223etc. He comprobado la replicación mysql haciendo show master statusy show slave statusestán usando algunos archivos mysql-bin en ciertas posiciones, pero supongo que todos los demás archivos bin son restos que ya no se usarán. En este caso, ¿es seguro eliminar todos esos archivos mysql-bin, excepto los que apunta la replicación actualmente?

Si es seguro eliminarlo, ¿hay algo que pueda hacer para eliminar automáticamente esos archivos una vez que no estén en uso?

No los elimine solo en el sistema operativo.

Debe dejar que mysqld lo haga por usted. Así es como mysqld lo maneja:

El archivo mysql-bin.[index]mantiene una lista de todos los registros binarios que mysqld ha generado y rotado automáticamente. Los mecanismos para limpiar los binlogs junto con mysql-bin.[index]son:

PURGE BINARY LOGS TO 'binlogname';
PURGE BINARY LOGS BEFORE 'datetimestamp';

Esto borrará todos los registros binarios antes del binlog o la marca de tiempo que acaba de especificar.

Por ejemplo, si corres

PURGE BINARY LOGS TO 'mysql-bin.000223';

Esto borrará todos los registros binarios anteriores mysql-bin.000223.

Si tu corres

PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;

Esto borrará todos los registros binarios antes de la medianoche hace 3 días.

Si desea que binlog se elimine automáticamente y se mantenga durante 3 días, simplemente configure esto:

mysql> SET GLOBAL expire_logs_days = 3;

luego agregue esto a /etc/my.cnf

[mysqld]
expire_logs_days=3

y mysqld los borrará por ti

MOSTRAR ESTADO ESCLAVO \ G

Esto es critico. Cuando corras SHOW SLAVE STATUS\G, verás dos registros binarios del Maestro:

• Master_Log_File
• Relay_Master_Log_File

Cuando la replicación tiene poco o ningún retraso, estos generalmente tienen el mismo valor. Cuando hay mucho retraso de replicación, estos valores son diferentes. Solo para hacerlo simple, elija lo que Relay_Master_Log_Filesea, y regrese al Maestro y ejecute

PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';

De esa manera, la replicación no se interrumpe.

Esto realmente depende de su estrategia de respaldo. Una de las principales razones para mantener los registros binarios es restaurar su base de datos a un "punto en el tiempo". Si su base de datos falla y requiere restauración, debería restaurar la última copia de seguridad completa y luego reproducir los registros binarios comenzando por la posición de la copia de seguridad completa.

Por lo tanto, si hace una copia de seguridad completa todos los días y tiene un valor de 7 días de registros binarios, es probable que pueda eliminar los últimos 4 a 6 días de registros binarios. Puede controlar cuántos días de registros binarios se mantienen con la expire_logs_daysconfiguración.

Puede eliminar los registros binarios que no necesita viendo primero cuál es el registro más antiguo que desea mantener:

ls -lh /path/to/binary/logs/mysql-bin.0*

y luego en mysql:

mysql> PURGE BINARY LOGS TO 'mysql-bin.XXXXX';

Prueba esto:

RESET MASTER;

como decía el documento :

RESET MASTER le permite eliminar cualquier archivo de registro binario y su archivo de índice de registro binario relacionado, devolviendo el maestro a su estado antes de iniciar el registro binario.

Esto eliminará todos los archivos de registro binarios relacionados, que pueden no ser lo que desea.