Consulte Descripción general del registro binario para obtener una descripción general de lo que es el registro binario y Activación del registro binario para saber cómo asegurarse de que se esté ejecutando en su sistema.

Para obtener detalles sobre el uso del registro binario para la replicación, consulte la sección Replicación.

Purga de archivos de registro

Para eliminar todos los archivos de registro binarios en el servidor, ejecute el comando RESET MASTER. Para eliminar todos los registros binarios antes de una determinada fecha y hora, o hasta cierto número, utilice PURGAR REGISTRO BINARIO.

Si un esclavo está activo pero aún no ha leído de un archivo de registro binario que intenta eliminar, la declaración fallará con un error. Sin embargo, si el esclavo no está conectado y aún tiene que leer un archivo de registro que elimine, el archivo se eliminará, pero el esclavo no podrá continuar replicando una vez que se conecte nuevamente.

Los archivos de registro también se pueden eliminar automáticamente con la variable de sistema expire_logs_days. Se establece en 0 de forma predeterminada (sin eliminación), pero se puede establecer en un tiempo, en días, después del cual se eliminará automáticamente un archivo de registro binario. Solo se comprobará que los archivos de registro sean más antiguos que expire_logs_days al rotar el registro, por lo que si su registro binario solo se llena lentamente y no alcanza el tamaño máximo_binlog_size diariamente, es posible que aún se conserven los archivos de registro más antiguos. También puede forzar la rotación de registros y, por lo tanto, las eliminaciones de caducidad, ejecutando FLUSH BINARY LOGS de forma regular. Establezca siempre expire_logs_days más alto que cualquier posible retraso del esclavo.

Si el archivo de índice de registro binario se ha eliminado o se ha editado manualmente de forma incorrecta, todas las formas anteriores de depuración de archivos de registro fallarán. El archivo .index es un archivo de texto sin formato y se puede volver a crear o editar manualmente para que solo enumere los archivos de registro binarios que están presentes, en orden numérico / por antigüedad.

Ejemplos de

PURGEBINARY LOGS TO'mariadb-bin.000063';
PURGEBINARY LOGS BEFORE '2013-04-22 09:55:22';

Purga segura de archivos de registro binarios durante la replicación

Para asegurarse de que la replicación no se interrumpa al eliminar los archivos de registro, realice los siguientes pasos:

  • Obtenga una lista de archivos de registro binarios en el maestro ejecutando SHOW BINARY LOGS.
  • Vaya a cada servidor esclavo y ejecute SHOW SLAVE STATUS para verificar qué archivo de registro binario está leyendo cada esclavo.
  • Encuentre el archivo de registro más antiguo que todavía está siendo leído por un esclavo. No se necesitarán archivos de registro antes de este.
  • Si lo desea, haga una copia de seguridad de los archivos de registro que se eliminarán
  • Purgue todos los archivos de registro antes (sin incluir) el archivo identificado anteriormente.

Formato de registro binario

Hay tres formatos para el registro binario. El valor predeterminado es el registro basado en declaraciones, mientras que el registro basado en filas y una combinación de los dos formatos también son posibles. Consulte Formatos de registro binarios para una discusión completa.

Registro selectivo en el registro binario

De forma predeterminada, se registran todos los cambios en los datos o la estructura de los datos. Este comportamiento se puede cambiar iniciando el servidor con el --binlog-ignore-db=database_name o --binlog-do-db=database_nameopciones.

--binlog-ignore-db=database_name especificó una base de datos para ignorar con fines de registro, mientras --binlog-do-db=database_name no registrará ninguna declaración a menos que se aplique a la base de datos especificada.

Ninguna opción acepta listas delimitadas por comas de varias bases de datos como opción, ya que el nombre de una base de datos puede contener una coma. Para aplicar a múltiples bases de datos, use la opción varias veces.

--binlog-ignore-db=database_name se comporta de manera diferente dependiendo de si se usa el registro basado en instrucciones o en filas. Para el registro basado en declaraciones, el servidor no registrará ninguna declaración donde base de datos predeterminada es nombre_base_datos. La base de datos predeterminada se establece con la instrucción USE.

Similar, --binlog-do-db=database_name también se comporta de manera diferente dependiendo de si se utiliza el registro basado en instrucciones o en filas.

Para el registro basado en declaraciones, el servidor solo registrará declaraciones donde el base de datos predeterminada es nombre_base_datos. La base de datos predeterminada se establece con la instrucción USE.

Para el registro basado en filas, el servidor registrará cualquier actualización de cualquier tabla en las bases de datos nombradas, independientemente de la base de datos actual.

Ejemplos de

Suponga que el servidor ha comenzado con la opción --binlog-ignore-db=employees. El siguiente ejemplo es se registra si se utiliza el registro basado en declaraciones, y no es registrado con registro basado en filas.

USE customers;UPDATE employees.details SET bonus=bonus*1.2;

Esto se debe a que el registro basado en declaraciones examina la base de datos predeterminada, en este caso, customers. Ya que customers no se especifica en la lista de ignorados, la declaración se registrará. Si se usa el registro basado en filas, el ejemplo no se registrará ya que las actualizaciones se escriben en las tablas en el employees base de datos.

Supongamos, en cambio, que el servidor comenzó con la opción --binlog-do-db=employees. El siguiente ejemplo no es se registra si se utiliza el registro basado en declaraciones, y es registrado con registro basado en filas.

USE customers;UPDATE employees.details SET bonus=bonus*1.2;

Esto se debe nuevamente a que el registro basado en declaraciones examina la base de datos predeterminada, en este caso, customers. Ya que customers no se especifica en la lista de tareas, la declaración no se registrará. Si se utiliza el registro basado en filas, el ejemplo se registrará a medida que se escriban las actualizaciones en las tablas del employees base de datos.

Efectos de los errores de disco completo en el registro binario

Si MariaDB encuentra un error de disco lleno al intentar escribir en un archivo de registro binario, seguirá reintentando la escritura cada 60 segundos. Los mensajes de registro se escribirán en el registro de errores cada 600 segundos. Por ejemplo:

2018-11-272:46:46140278181563136[Warning] mysqld: Diskisfull writing '/var/lib/mariadb-bin.00001'(Errcode: 28"No space left on device"). Waiting for someone to free space...(Expect up to60 secs delay for server tocontinueafter freeing disk space)2018-11-272:46:46140278181563136[Warning] mysqld: Retry in60 secs. Message reprinted in600 secs

Sin embargo, si MariaDB encuentra un error de disco completo al intentar abrir un nuevo archivo de registro binario, desactivará el registro binario por completo. Se escribirá un mensaje de registro como el siguiente en el registro de errores:

2018-11-273:30:49140278181563136[ERROR] Could notopen'/var/lib/mariadb-bin.00002 for logging (error 28). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
2018-11-27  3:30:49 140278181563136 [ERROR] mysqld: Error writing file '(null)' (errno: 9 "Bad file descriptor")
2018-11-27  3:30:49 140278181563136 [ERROR] mysqld: Error writing file '(null)' (errno: 28"No space left on device")

Ver también

  • PURGA DE TRONCOS

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.