Por defecto, los logs retardados se nombran usando nombres de ficheros de la forma host_name-relay-bin.nnnnnn, donde host_name es el nombre del servidor esclavo y nnnnnn es un número de secuencia. Los ficheros de logs retardados sucesivos en MySQL 5.0 se crean usando números de secuencia sucesivos, comenzando a partir de 000001. El esclavo guarda los logs retardados en unso en un fichero índice. El nombre del índice del log retardado por defecto es host_name-relay-bin.index. Por defecto, estos ficheros se crean en el directorio de datos del esclavo. Por defecto los nombres de fichero pueden cambiarse con las opciones de servidor --relay-log y --relay-log-index . Consulte Sección 6.8, “Opciones de arranque de replicación”.

Los logs retardados tienen el mismo formato que los logs binarios, y pueden leerse usando mysqlbinlog. Un log retardado se borra automáticamente por el flujo SQL en cuanto ha ejecutado todos sus eventos y no los necesita más. No hay mecanismo explícito para borrar logs retardados, ya que el flujo SQL se encarga de ello. Sin embargo, FLUSH LOGS rota los logs retardados, lo que influye cuando el flujo SQL los borra.

Un log retardado se crea bajo las siguientes condiciones:

Un servidor esclavo de replicación crea dos pequeños ficheros adicionales en el directorio de datos. Estos ficheros de estado se llaman master.info y relay-log.info por defecto. Contienen información como la mostrada en la salida del comando SHOW SLAVE STATUS (consulte Sección 13.6.2, “Sentencias SQL para el control de servidores esclavos” para una descripción de este comando). Como ficheros en disco, sobreviven una parada del servidor esclavo. La siguiente vez que arranca el servidor esclavo, lee estos ficheros para determinar hasta dónde ha procesado los logs binarios del maestro y sus propios logs retardados.

El fichero master.info lo actualiza el flujo de entrada/salida. En MySQL 5.0, la correspondencia entre las líneas en el fichero y las columnas mostradas porSHOW SLAVE STATUS es la siguiente:

El fichero relay-log.info lo actualiza el flujo SQL. La correspondencia entre las líneas en el fichero y las columnas mostradas por SHOW SLAVE STATUS se muestran aquí:

Cuando hace una copia de seguridad de los datos del esclavo, debe incluir también estos dos ficheros, junto con sus ficheros de log retardado. Son necesarios para reanudar la replicación tras restaurar los datos del esclavo. Si pierde los logs retardados pero todavía tiene el fichero relay-log.info , puede examinarlo para determinar hasta dónde ha ejecutado el flujo SQL en el log binario del maestro. Luego puede usar CHANGE MASTER TO con las opciones MASTER_LOG_FILE y MASTER_LOG_POS para decirle al esclavo que vuelva a leer los logs binarios a partir de ese punto. Por supuesto, esto requiere que los logs binarios existan en el servidor maestro.

Si su esclavo está sujeto a replicación de comandos LOAD DATA INFILE , también debe incluir en la copia de seguridad cualquier fichero SQL_LOAD-* que existe en el directorio que el esclavo usa para este propósito. El esclavo necesita estos ficheros para reanudar replicación de cualquier operación LOAD DATA INFILE interrumpida. La localización del directorio se especifica usando la opción --slave-load-tmpdir . Si valor por defecto, si no se especifica, es el valor de la variable tmpdir .