MariaDB / Replicacion

Bienvenidos sean a este post, hoy comenzaremos a hablar sobre las replicaciones.

Actualmente mariadb tiene incorporada la replicacion y si bien esta es una de las caracteristicas mas viejas y avanzadas, su primera aparicion fue en la version 3.23.15 de mysql, en ese momento no solamente no incluia a InnoDB sino que tampoco soportaba caracteristicas como las vistas o la instruccion UNION, y si bien en sus primeras versiones lo unico que hacia era guardar en logs todas las instrucciones SQL del amo y enviarlas a sus esclavos hoy con el pasar del tiempo se puede ver todo lo que mejoro, en este post mencionamos que para poder hacer la replicacion necesitamos tener activo al log binario dado que este lleva un control de todos los eventos que modifican las bases de datos, este soporta tres formatos:

• Instruccion, almacena todas las instrucciones que modifican
• Fila, almacena las modificaciones realizadas
• Mezclada, almacena las instrucciones que se pueden usar, de lo contrario almacena la modificacion

En este post explicamos un poco mas a detalle cada uno de los formatos disponibles, ahora dependiendo del formato que elijamos se define que el tipo de replicacion es basado en instrucciones o en filas, la replicacion en mariadb se la denomina replicacion asincronica, lo cual implica que no se necesita una conexion permanente entre el amo y sus esclavos.

Trabajando de esta forma podemos hacer que los usuarios hagan los queries contra los esclavos, uno de los grandes beneficiados de esto son las cargas de trabajo de lectura pesadas, ya que conectando muchos esclavos al amo permite distribuir estos queries entre ellos, a su vez un esclavo puede ser el amo de otro, para entender el concepto hablemos de un ejemplo.

Tenemos un servidor A que sera el amo del servidor B, a su vez el servidor B es el amo del servidor C, si por alguna razon se cae el servidor B se interrumpe temporalmente la replicacion en el servidor C, pero si B pierde datos podemos usar al servidor C para recuperarlo, inclusive podemos hacer que el servidor C sea amo del servidor A, si hacemos esto se formara un anillo y a esto se lo llama replicacion circular, la principal ventaja es que permite leer y escribir en cualquiera de los servidores, tambien que la consistencia de datos esta garantizada porque cada modificacion eventualmente se replicara en todos los servidores del anillo, la contra mas grande es que ningun servidor tiene la informacion siempre actualizada a lo ultimo.

A partir de la version 10.0 de mariadb permite la replicacion de multiples origenes (multisource replication), esta nos permite que cada esclavo replique datos desde multiples amos, no tenemos forma de manejar los conflictos en mariadb por lo tanto, el amo debe contener diferentes datos, ya que no es posible replicar la misma base de datos desde dos o mas amos, este replicacion nos permite usar un solo equipo, o un numero limitado de equipos, para replicar datos desde varios amos, otra cuestion a tener en cuenta son los entornos de replicacion donde todos los amos y esclavos deben tener la misma version de mariadb, la replicacion desde version viejas a versiones nuevas no funcionan, en cambio desde versiones nuevas a viejas deberian funcionar correctamente pero puede generar problemas, otra ventaja que tenemos es la posibilidad de usar servidores de mysql en la mima topologia de mariadb siempre que respetemos el tema de las versiones.

En mariadb la replicacion utiliza tres tipos de threads:

Donde corre	Nombre del thread
master	thread de volcado del log binario
slave	thread de SQL E/S
slave	thread de SQL esclavo

Las conexiones entre amos y esclavos son solicitados por los esclavos, cuando se inicia un esclavo este crea el thread de SQL E/S, este se conecta al amo y solicita eventos que deben ser replicados, pasando al amo este corre al thread de volcado de log binario, siendo este un daemon que acepta todas las solicitudes de los threads de SQL E/S de los esclavos y les envia los eventos del log binario, si utilizamos a SHOW SLAVE STATUS veremos que esta es llamada Slave_IO_running, en cambio SHOW PROCESSLIST muestra a este thread como Binlog Dump, volviendo al thread de SQL E/S este no ejecuta los eventos sino que los almacena en un log ubicado en el esclavo llamado log de retransmision esclavo (slave relay log), por ultimo tenemos al thread de SQL esclavo que sera encargado de leer el log generado anteriormente y si procedera a ejecuar los eventos en el esclavo.

A partir de mariadb 10.0 se introdujo una nueva caracteristica llamada replicacion en paralelo (parallel replication), esta consiste de iniciar un pool de threads que tiene la capacidad de aplicar muchos eventos de forma paralela, cada thread de este pool es llamado thread trabajador (worker thread), tengan en cuenta que no todos los eventos puede ser aplicados por threads paralelos, mariadb aun ejecutara algunas operaciones de forma secuencial, siempre que esto sea necesario para replicar correctamente los datos, esta caracteristica no esta activa de manera predeterminada, para activarla debemos establecer un valor en la variable @@slave_parallel_threads ubicada en el amo, este valor representa al numero de threads trabajadores que se iniciaran en cada esclavo, como consecuencia todos los esclavos que replican del mismo amo tendran el mismo numero de thread trabajadores, tambien si un esclavo replica multiples amos el mismo numero de threads trabajadores debe ser configurado en todos los amos.

Pasemos a hablar sobre los logs esclavos, estos se encargan de almacenar informacion sobre la configuracion de replicacion y el progreso actual, esta no debe perderse inclusive si ocurre un incidente con el esclavo, asi que cada esclavo mantiene tres logs:

• relay log, contiene los eventos que fueron recibidos por los logs binarios del amo
• master log, almacena la informacion que es necesaria para conectarse al amo, asi como las coordenadas del log binario del amo
• relay log information, almacena informacion sobre el ultimo evento del relay log que ha sido aplicado por el thread de SQL esclavo o un thread trabajador

El primer log debe ser escrito en archivo, en cambio los ultimos dos pueden ser escritos en archivos pero tambien pueden ser escritos dentro de las tablas del sistema en la base mysql, incluso en las replicaciones de multiples origenes cada esclavo tiene un log para cada tipo.

En resumen, hoy hemos visto una introduccion a replicacion, que es, como se compone, cuales tenemos, algunas caracteristicas de ambas y un par de detalles mas sobre las distintas formas, espero les haya sido de utilidad 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.