¿Es seguro eliminar los registros binarios mysql rotados?

Question

Tengo un servidor MySQL con registro binario activo. Una vez que el archivo de registros de día está "girado", es decir, MySQL parece dejar de escribirle y crea un nuevo archivo de registro. Por ejemplo, actualmente tengo estos archivos en/var/lib/mysql

-rw-rw---- 1 mysql mysql 10485760 Jun  7 09:26 ibdata1
-rw-rw---- 1 mysql mysql  5242880 Jun  7 09:26 ib_logfile0
-rw-rw---- 1 mysql mysql  5242880 Jun  2 15:20 ib_logfile1
-rw-rw---- 1 mysql mysql  1916844 Jun  6 09:20 mybinlog.000004
-rw-rw---- 1 mysql mysql 61112500 Jun  7 09:26 mybinlog.000005
-rw-rw---- 1 mysql mysql 15609789 Jun  7 13:57 mybinlog.000006
-rw-rw---- 1 mysql mysql       54 Jun  7 09:26 mybinlog.index

y mybinlog.000006 está creciendo.

¿Puedo simplemente tomar mybinlog.000004 y mybinlog.000005, abrochalos y transferir a otro servidor, o necesito hacer algo más antes?

¿Qué información se almacena en mybinlog.index? ¿Solo la información sobre el último registro binario?

ACTUALIZAR: Entiendo que puedo eliminar los registros con registros binarios de purga que actualiza el archivo mybinlog.index. Sin embargo, necesito transferir registros a otra computadora antes de eliminarlos (pruebo si la copia de seguridad es válida en otra máquina). Para reducir el tamaño de la transferencia, deseo BZIP2 los archivos. ¿Qué harán los registros binarios de Purge si los archivos de registro ya no están "allí"?

Answer 1

Finalmente encontré la respuesta en el sitio web de MySQL. En caso de que alguien necesite esta información:

Antes de MySQL 5.0.60, los registros binarios de purga a los registros binarios de purga antes no se comportaron de la misma manera (y ninguno se comportó correctamente) cuando los archivos de registro binarios enumerados en el archivo .dex se habían eliminado del sistema por algún otro medio (como usar RM en Linux). Comenzando con MySQL 5.0.60, ambas variantes de la declaración fallan con un error en tales casos. (Error#18199, error#18453) Para manejar dichos errores, editar el archivo .index (que es un archivo de texto simple) manualmente para asegurarse de que enumera solo los archivos de registro binarios que realmente están presentes, luego ejecute nuevamente los registros binarios de Purge declaración que falló.

Esto significa que debería editar el archivo .dex manualmente y todo estará bien. Lo interesante es que el archivo .index es un archivo textual regular. Ni siquiera me di cuenta hasta ahora.

Answer 2

Puede eliminar los viejos registros binarios. En lugar de eliminarlos directamente, es más seguro usar el estado mySQL PURGE BINARY LOGS que también actualiza su mybinlog.index expediente. Este archivo almacena qué nombres de archivo se han utilizado para el registro binario, ver

http://dev.mysql.com/doc/refman/5.0/en/purge-binary-logs.html

Además, puede configurar su servidor MySQL para eliminar los registros binarios antiguos automáticamente. Establecer las variables max_binlog_size y expire_logs_days en la configuración de su servidor a los valores apropiados.

los ibdata y ib_logfile Los archivos no tienen nada que ver con el registro binario. Son utilizados por el motor de almacenamiento innodb. No se equivoque con el hecho de que no parecen crecer: si tiene tablas innodb en su servidor, estos archivos son importantes y eliminarlos puede dar lugar a la pérdida de datos. Puedes leer más sobre innodb en los documentos:

http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html

Answer 3

mysql> PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY; 

¡Elimine todos los archivos de bin antes de los 3 días!

o

PURGE MASTER LOGS BEFORE '2010-10-08 00:00:00';

Answer 4

mysql-bin.index generalmente lleva todos los archivos .bin. Si ha eliminado algunos archivos, edite. Si ha eliminado todos los archivos .bin, elimine vacío el archivo .index. Esto resolverá tu problema.