MariaDB / Logs de replicacion

Bienvenidos sean a este post, hasta ahora vimos como trabaja la replicacion pero tanto el log del amo como del esclavo empezaran a crecer pero tenemos que rotar y eliminar a los archivos viejos para evitar quedarnos sin espacio, lo cual veremos en este post.

El nombre actual de archivo de nuestro log binario es determinado por la opcion –log-bin al inicio, si se especifica una extension esta se ignora y solo se usa el nombre base, sabemos que de manera predeterminada se escribe en la carpeta data de la distribucion, esta variara en cada S.O, y si no especificamos ninguno se utiliza el nombre del host seguido del sufijo -bin, en el servidor tenemos una variable llamada max_binlog_size la cual determina el tamaño maximo del archivo actual, cuando se alcanza el tamaño se procede a la rotacion del archivo:

1. Se renombra el archivo actual
2. Se crea uno nuevo con el mismo nombre

Los nombres de los archivos viejos siempre utilizan el siguiente patron:

<nombre_base>.<id_programa>

Siendo nombre_base el nombre del archivo, por ejemplo en su forma mas basica el hostname seguido del sufijo -bin y id_programa sera una secuencia numerica de seis digitos que se incrementara con cada nueva rotacion, veamos un ejemplo:

dbn001vrt-bin.000001

Tambien tenemos un archivo de indice que sigue este patron de nombre de archivo:

<nombre_base>.index

Siendo el nombre_base igual al explicado anteriormente, para cambiarlo debemos usar la opcion –log-bin-index al inicio, este archivo que se genera puede ser leido y contiene una lista de los archivos viejos existentes ademas del actual, no deberia ser borrado o editado manualmente, tambien sucede la rotacion cuando se reinicia al servidor, y cuando se ejecuta alguno de estos comandos:

• FLUSH LOGS
• FLUSH BINARY LOGS

Siempre es conveniente mantener una cierta cantidad de archivos viejos del log binario, dado que tambien nos pueden ser utiles para los backups incrementales, tal como vimos en este post, esto tambien nos puede ser util para la replicacion, no se olviden que los esclavos no reciben inmediatamente los eventos que se escribieron en los logs, estos pueden tener una demora y sea necesario que lean archivos que han sido generados hace dias o meses, para obtener los archivos del log se usa la instruccion SHOW BINARY LOGS, veamos un ejemplo:

MariaDB [(none)]> SHOW BINARY LOGS;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000040 |      3402 |
| binlog.000041 |       384 |
| binlog.000042 |       342 |
| binlog.000043 |       390 |
| binlog.000044 |      6516 |
| binlog.000045 |       342 |
| binlog.000046 |       737 |
| binlog.000047 |       932 |
| binlog.000048 |       940 |
| binlog.000049 |      2891 |
| binlog.000050 |      2410 |
| binlog.000051 |       359 |
+---------------+-----------+
12 rows in set (0.00 sec)

Tenemos la variable @@expire_logs_days la cual determina cuando expiran los archivos de log, si su valor no es de 0 hace que sean eliminados los archivos viejos de log despues de pasado los numeros de dias, puede ser un arma de doble filo salvo que sepamos perfectamente que los esclavos no necesitaran de estos archivos que sean eliminados, si esto no se considera correctamente puede hacer que un esclavo quede inservible, esto puede derivar en un problema de red e inclusive detener la replicacion, una alternativa es eliminar los archivos viejos por medio de instrucciones SQL y si bien este metodo puede ser mas seguro sera mas trabajoso, por esta razon una buena practica es hacerlo via script que sea ejecutado via trabajo de cron, les paso un ejemplo de procedimiento de eliminacion de archivos viejos que no sean necesarios:

• Ejecuta a SHOW SLAVE STATUS
• Se devuelve una fila por cada esclavo, en la columna Master_Log_File indica cual archivo de log binario esta leyendo el esclavo, en el script podemos hacer que lo ordene alfabeticamente
• Vamos a suponer que el archivo mas viejo se llama binlog-000050, para poder eliminar los archivos viejos usaremos: PURGE BINARY LOGS TO ‘binlog.000050’;

Aunque esta instruccion tambien puede ser usada para borrar archivos que contengan instrucciones mas viejas que una fecha informada, veamos un ejemplo:

PURGE BINARY LOGS BEFORE '2020-04-01 0:0:0';

Vamos a suponer que tenemos un servidor solitario que se convertira en un amo de replicacion, nuestro primer paso sera hacer un backup de todos los datos actuales, luego los cargamos a los esclavos, una vez realizado podemos borrar los archivos del log binario porque no queremos que se replique nuevamente el ultimo evento hasta este punto, para hacer esto usamos a RESET MASTER, esta instruccion borra todos los archivos del log, los indices y crea un nuevo archivo vacio con la extension 000001.

Ahora hablemos de los archivos del log de relay, este sigue las mismas reglas que el log binario, de manera predeterminada los archivos siguen este patron:

<hostname>-relay-bin.<id_sec>

Siendo hostname el nombre del esclavo que hace de host seguido del sufijo -relay-bin y la extension id_sec que es la misma secuencia del log binario, para especificar un nombre distinto se debe usar la opcion –relay-log al inicio, aqui tambien tenemos un archivo de indice que trabaja de la misma forma que el log binario, el patron del nombre del archivo de indice es:

<hostname>-relay-bin.index

De manera similar al log binario y el nombre puede ser modificado con la opcion –relay-log-index al inicio, ambos archivos tambien se ubican en el directorio data si no se especifica alguno, al igual que el log binario si el archivo alcanza el valor maximo establecido en la variable max_relay_log_size crea un nuevo archivo y renombra al anterior, si este valor es de 0 utiliza el valor de max_binlog_size que no puede ser 0.

Un nuevo log es creado cada ve que se inicia el thread de E/S, las siguientes instrucciones nos permiten crear nuevos archivos:

• FLUSH RELAY LOGS
• FLUSH LOGS

Cuando el thread de SQL del esclavo ejecuto los ultimos eventos del log de relay, elimina automaticamente el archivo a menos que sea el archivo actual, no tenemos forma o necesidad de cambiar este mecanismo, por ultimo el log de informacion del amo es almacenado de manera predeterminada al archivo master.info en el directorio data, el nombre y el path pueden ser modificadas con la opcion –master-info-file al inicio, el log de informacion de relay de manera predeterminada es almacenado en relay-log.info tambien en el directorio data, el nombre y el path podemos cambiarlo con la opcion –relay-log-info-file al inicio, estos archivos poseen toda la informacion que nos desplegara la instruccion SHOW SLAVE STATUS cuando sea ejecutado, sin embargo mientras los esclavos esten corriendo esta informacion estara desactualizada, porque el estado de los datos de la replicacion esta almacenado en memoria, los archivos estaran siempre actualizados cuando los esclavos no estan corriendo, finalmente estos archivos no crecen, no necesitan rotarse o mantenimiento especial.

En resumen, hoy hemos visto a los logs de replicacion, como son, para que sirven, sus similitudes, sus diferencias, como podemos rotarlas y/o mantenerlas, espero les haya sido util sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.