MariaDB / Trabajando con la replicacion

Bienvenidos sean a este post, hoy veremos otras tareas para hacer entre el amo y el esclavo.

Reconfigurando un esclavo existente

Hasta el post anterior vimos como configurar una replicacion entre amo y esclavos pero que sucede si debemos reconfigurar a un esclavo porque restauramos una vieja base de datos en un amo o las reglas de filtrado no se establecieron correctamente? sea cual sea el inconveniente necesitamos que nuestro esclavo se olvide todos los datos replicados hasta ahora y se inicie nuevamente, despues del reinicio el esclavo necesita replicar el log binario desde el inicio, por lo tanto debe olvidar las coordenadas actuales, para esto entra en accion la instruccion RESET SLAVE la cual borrara los archivos de log esclavos, como esto no puede ser hecho mientras el servidor esta corriendo debemos detenerlo temporalmente, veamos el siguiente ejemplo de como hacerlo:

MariaDB [(none)]> STOP SLAVE;
Query OK, 0 rows affected (0.17 sec)
MariaDB [(none)]> RESET SLAVE;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> START SLAVE;
Query OK, 0 rows affected (0.18 sec)

Es tan simple como eso, se detiene el esclavo, ejecutamos a la instruccion que resetea al esclavo y luego lo iniciamos nuevamente.

Importando los datos dentro de un amo

Otra situacion que podemos tener es la de reemplazar un amo viejo con uno nuevo, ya sea porque el amo viejo es lento o su hardware se daño, sin importar la razon deberemos cargar los datos de este a uno nuevo, una alternativa que tenemos es hacerlo cuando los esclavos estan corriendo y conectados al amo, para este caso usaremos un volcado de los datos a traves de mysqldump, del cual hemos hablado en este post, y en este tambien vimos como cargarlo, el volcado se replicara automaticamente a los esclavos.

Otra alternativa para usar backups logicos es copiar los archivos, pero para este caso el backup no se replicara automaticamente, si los esclavos estan corriendo tendremos que copiar los backups fisicos en los directorios de datos de los esclavos, de esta forma estaran provisto con todos los datos del amo viejo antes de comenzar a replicar desde el nuevo amo.

Importando datos de un amo a un esclavo

Si bien no lo comentamos pero si lo mencionamos o insinuamos, un entorno de replicacion no es estatico dado que se agregan nuevos esclavos en algun momento, ya sea para obtener mas redundancia o para balancear la carga de trabajo a traves de un alto numero de servidores de mariadb, cualquiera sea el caso necesitamos cargar los datos del amo actual dentro de los nuevos esclavos, para despues hacer que nuestros esclavos repliquen.

Al igual que vimos en el caso anterior podemos utilizar un backup logico fisico y copiarlo en el esclavo, dado que no existe diferencia entre un backup y una replicacion, tambien se puede usar mysqldump dado que puede hacerse un volcado de manera mas rapida desde el amo o tambien desde otro esclavo lo cual nos permite quitar un poco de carga al amo.

Volcando datos de un amo

Cuando se toma un backup de un amo que debe ser restaurado dentro de un esclavo debemos usar la opcion –master-data la cual nos sera particularmente utiles, esta se encarga de agregar la instruccion CHANGE MASTER TO al volcado, esto hara que los esclavos se configuren automaticamente para replicar al amo desde las coordenadas correctas, tambien tenemos la opcion –delete-master-logs que ejecuta la instruccion PURGE BINARY LOGS en el amo y esta elimina todo los archivos del log binario pero sobre este tema hablaremos mas adelante.

Volcando datos de un esclavo

Como mencionamos si el amo ya posee un esclavo podemos hacer el volcado desde este para no sobrecargar al amo, el principal parametro que debemos usar con mysqldump es –dump-slave, si bien es similar a –master-data esta produce una instruccion CHANGE MASTER TO diferente, cuando usamos –master-data la herramienta asume que estamos replicando desde un servidor a los que se conectan, en cambio –dump-slave asume que el servidor es el esclavo y CHANGE MASTER TO sera usado para replicar a su servidor, si bien –dump-slave incluye las coordenadas de replicacion en el volcado pero no incluye los hostname y puertos del amo.

Para asegurarnos que pasaremos todos los datos debemos incluir la opcion –include-master-host-port ya que esta opcion enviara el hostname y el puerto del amo y seran incluidos en el CHANGE MASTER TO, esto nos hace la configuracion del esclavo mas facil al menos que el volcado sea desde otro esclavo o hayan cambiado los datos del amo por alguna razon, por tambien tenemos el argumento –apply-slave-statements el cual agregara al volcado las instruccion STOP SLAVE y START SLAVE por delante y por detras respectivamente de CHANGE MASTER TO, esto es especialmente util si el esclavo destino esta corriendo, si aun no esta corriendo el START SLAVE hara que comience a replicar inmediatamente pero nosotros podemos no querer esto porque necesitamos chequear las consistencias de los datos antes de que el esclavo comience a trabajar.

SET SQL_LOG_BIN

Esta instruccion nos permite establecer si se llevara un registro de las instrucciones subsecuentes dentro del log binario, esto solo afecta a sesion actual, es decir que las instrucciones no ingresadas al log binario del amo no seran replicadas a los esclavos, consideremos el siguiente ejemplo:

MariaDB [test]> SET SQL_LOG_BIN = 0;
Query OK, 0 rows affected (0.00 sec)
MariaDB [test]> /* esta instruccion no se registrara o replicara */
    -> DROP TABLE orders;
Query OK, 0 rows affected (0.38 sec)
MariaDB [test]> SET SQL_LOG_BIN = 1;
Query OK, 0 rows affected (0.00 sec)

La variable @@skip_replication

Esta variable es muy similar a la instruccion SET SQL_LOG_BIN sin embargo no inhibe el registro de instrucciones, solo causa que las instrucciones sean marcadas como skip_replication en el log binario, los esclavos recibiran estos eventos pero su conducta dependera del valor que posea la variable @@replicate_events_marked_for_skip, veamos estos valores:

• REPLICATE, hace que los eventos sean replicados; se ignora a la marca, este es el valor predeterminado
• FILTER_ON_SLAVE, hace que el esclavo ignore tales eventos, se lo recibira y se lo registrara, si existe un log binario en el esclavo se preservara con la misma marca
• FILTER_ON_MASTER, con esta opcion el esclavo no lo recibe de ninguna forma

Filtrando la replicacion de eventos en los esclavos

Los esclavos poseen tres variables dinamicas que nos permiten prevenir que algunas tablas o bases de datos enteras sean replicadas, podemos usar una lista de argumentos separados por comas en estas variables, aunque sean dinamicas siempre es recomendable detener al esclavo antes de cambiar los valores, veamos cuales son estas variables:

• @@replicate_skip_db, esto evita la replicacion las bases de datos especificadas
• @@replicate_skip_table, evita la replicacion de las tablas especificadas, el formato para informarlas debe ser nombre_db.nombre_tabla, tambien nos permite omitir las instrucciones multibases
• @@replicate_wild_skip_tables, es similar a la anterior pero nos permite utilizar comodines como % o _, por ejemplo si usamos ‘test%.%’ signifca que omitira todas las tablas de las bases que comiencen con la palabra test

Como dijimos al principio tambien podemos hacer que se omitan bases de datos o tablas completas, para esto podemos usar las siguientes variables que son complementos a las anteriores:

• @@replicate_do_db
• @@replicate_wild_do_tables
• @@replicate_wild_do_tables

Checksums de los eventos del log binario

Desde la version 5.3 de mariadb se nos permite escribir el checksum en el log binario, esto no esta activo de manera predeterminada porque modifica el formato del log binario generando una incompatibilidad, para permitirlo debemos pasarle el valor de 1 a la variable @@binlog_checksum, activandola hace la replicacion mas confiable pero deberiamos evitar cuando la performance de los esclavos es un inconveniente, veamos algunas situaciones donde nos podemos beneficiar de los checksums:

• El thread esclavo de E/S verifica los checksums cuando los recibe de los amos si @@master_verify_checksum esta con el valor 1, su valor predeterminado es de 0
• El thread esclavo de SQL verifica los checksums si @@slave_sql_verify_checksum posee el valor de 1, el cual es su valor predeterminado
• La herramienta mysqlbinlog verifica los checksums si se lo invoca con la opcion –verify-binlog-checksum

Por ultimo todas las variables que afectan al checksum son dinamicas y podemos activarla y desactivarla sin inconvenientes.

En resumen, hoy hemos visto algunas acciones que podemos hacer sobre la replicacion una vez establecida, ya sea desde copiar entre amos, desde un amo a un esclavo, de un esclavo a un amo, tambien algunas acciones mas para nuestra replicacion que nos pueden beneficiar a la hora de trabajar con ellas, 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.