He usado PURGE BINARY LOGS y FLUSH LOGS, pero el directorio mysql todavía contiene estos archivos:
mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index
¿Hay alguna razón por la cual el uso de los comandos no funciona? Estos archivos están ocupando mucho espacio. Me gustaría deshacerme de ellos de forma segura.
Respuestas:
La PURGE BINARY LOGSinstrucción elimina todos los archivos de registro binarios enumerados en el archivo de índice de registro antes del nombre del archivo de registro o la marca de tiempo especificados. Los archivos de registro eliminados también se eliminan de la lista registrada en el archivo de índice, de modo que el archivo de registro dado se convierte en el primero de la lista.
Espero que hayas purgado los registros binarios hasta mysql-bin.000019usar el comando
PURGE BINARY LOGS TO 'mysql-bin.000019';Si necesita purgar todos los registros, haga clic en Me gusta
PURGE BINARY LOGS TO 'mysql-bin.000025';Esto eliminará los registros binarios hasta mysql-bin.000025.
ACTUALIZAR
Puedes probar
RESET MASTER;RESET MASTER Elimina todos los archivos de registro binarios enumerados en el archivo de índice, restablece el archivo de índice de registro binario para que esté vacío y crea un nuevo archivo de registro binario
Los efectos de RESET MASTERdifieren de los de PURGE BINARY LOGS en 2 formas clave:
RESET MASTER elimina todos los archivos de registro binarios que figuran en el archivo de índice, dejando solo un único archivo de registro binario vacío con un sufijo numérico de .000001, mientras que la numeración no se restablece mediante PURGE BINARY LOGS.
RESET MASTERno estaba destinado a usarse mientras se ejecutaban esclavos de replicación. El comportamiento de RESET MASTERcuando se usa mientras los esclavos están en ejecución no está definido (y, por lo tanto, no es compatible), mientras que PURGE BINARY LOGSpuede usarse de manera segura mientras los esclavos de replicación están en ejecución.
Si corres RESET MASTERcon Slaves conectados y corriendo, el hilo IO de cada Slave perderá inmediatamente su lugar. Por lo tanto, la replicación no funciona y tendrá que pasar tiempo obteniendo los datos de todos los esclavos sincronizados nuevamente. Si desea eliminar de forma segura los registros binarios de un maestro sin romper la integridad de la replicación, esto es lo que debe hacer:
SHOW SLAVE STATUS\Gen cada esclavo.Relay_Master_Log_File. Este es el registro binario cuya última declaración se ejecutó con éxito en Slave).SHOW SLAVE STATUS\G, determine cuál Relay_Master_Log_Filees la más antigua (por ejemplo, 'mysql-bin.00123').PURGE BINARY LOGS TO 'mysql-bin.00123';Ninguno de los esclavos perderá su lugar.El efecto general? Esto dejará registros binarios en el maestro cuyas declaraciones no se han ejecutado en todos los esclavos hasta el momento.
CHANGE MASTER TO, elimina todos los registros de retransmisión. Si Relay_Master_Log_filees así mysql-bin.00123, ese es el registro binario más antiguo en el Maestro que el Esclavo conoce. Si mysql-bin.00123ya no existe en el Maestro, podría perder el lugar adecuado para replicar si ejecuta alguno CHANGE MASTER TOen el Esclavo que no hace referencia a registros más nuevos. Esto se puede pasar por alto fácilmente y terminas rompiendo manualmente la replicación.
No estoy seguro de si esto es lo que te sucedió, pero en mi caso MySQL había dejado de "ciclar" los registros y el archivo mysql-bin.index se había "corrompido" con entradas de archivo binlog no válidas.
Específicamente, el archivo de índice comenzó en mysql-bin.000001 y llegó a mysql-bin.000220, pero de alguna manera comenzó de nuevo desde 001. Cuando comparé esto con los archivos en mi servidor, pude ver que tenía archivos de 001 a 022.
Al principio lo intenté PURGE LOGS TO 'mysql-bin.000022';pero esto no funcionó.
Al final detuve MySQL y edité manualmente el archivo de índice hasta que coincidiera con los archivos que tenía en mi servidor. Cuando reinicié MySQL, limpió los archivos binlog para respetar la expire_logs_daysconfiguración y comenzó a funcionar normalmente de nuevo.
PURGE LOGSsolo funciona bajo la configuración ideal: 1) cuando todos los registros binarios son consecutivos, 2) todos los registros binarios se nombran en el mysql-bin.indexarchivo, 3) No hay registros adicionales no mencionados mysql-bin.index. +1 !!!
En mi caso, PURGE BINARYsimplemente no estaba borrando nada.
Tenía mi partición al 100% de uso (tuve que limpiar un poco mi registro de consultas lentas para que hubiera suficiente espacio para que mysql se reiniciara), así que lo primero que hice fue cambiar /etc/my.cnfpara comentar la línea log-bin=mysql-bin(no era necesario en este servidor y olvidé eliminarlo), y luego reinicié mysql (esto era necesario porque había consultas en cola que impedían que PURGE BINARYse ejecutara).
Después de eso, corrí PURGE BINARYpero no pasó nada. Entonces leí el manual y descubrí que:
Esta declaración no tiene efecto si el servidor no se inició con la opción --log-bin para habilitar el registro binario.
Así que volví a habilitar log-bin=mysql-binen mi /etc/my.cnf, reinicié, PURGÉ los archivos (con éxito ahora), comenté la línea nuevamente y luego reinicié. Después de esto, los archivos se eliminaron y ya no se crearon.
Esto funciona para mí: (versión del servidor MySQL: 5.6.14)
PURGE BINARY LOGS BEFORE NOW();Elimina todos los registros binarios en mi sistema.
Puede eliminar fácilmente TODOS los registros con:
PURGE BINARY LOGS BEFORE NOW();O reemplace func NOW () por cualquier fecha entre comillas:
PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';O puede automatizar esta acción con expire_logs_days = 10my.cnf. Por defecto, expire_logs_days es 0 = nunca borre registros.
( fuente )