MariaDB / Configurando la replicacion paralela

Bienvenidos sean a este post, hoy hablaremos sobre el otro tipo de replicacion.

La forma mas usual de trabajo es que un servidor de base de datos procesa las solicitudes de varios clientes al mismo tiempo, si todas estas solicitudes no bloquean tablas o filas para garantizar la integridad de los datos se pueden procesar simultaneamente, antes de la version 10.0 de mariadb los esclavos usaban un solo thread para replicar todos los eventos que reciben del amo, debido a esta limitacion las operaciones de escritura eran mucha mas lentas en los esclavos, especialmente en entornos donde el amo podria ejecutar muchas escrituras no bloqueables, aunque a partir de la version 10.0 se agrego la posibilidad de usar multiples threads paralelos donde podemos aplicar los eventos de replicacion.

En este post mencionamos como era la replicacion paralela, esta no es usada de manera predeterminada pero para activarla debemos establecer un valor mayor a 0 en la variable @@slave_parallel_threads en el amo, el cual representa la cantidad de threads trabajadores paralelos que seran usados por todos los esclavos, veamos algunas de las variables que nos seran mas utiles en la replicacion paralela:

• @@slave_parallel_max_queued determina la cantidad de memoria que los esclavos deben usar para almacenar en cache los proximos eventos del log de relay no ejecutados todavia, cuando al menos el thread trabajador esta libre, los esclavos examinan este cache buscando eventos que pueden ser ejecutados en paralelo
• @@slave_domain_parallel_threads es util cuando se usa replicacion paralela en un esclavo que replica a varios amos, vamos a imaginar el siguiente ejemplo donde un esclavo replica a tres amos, supongamos que uno de ellos (al cual llamaremos master1) ejecuta una instruccion que lleva varias horas, esto puede ocurrir con tablas grandes, el esclavo necesitara replicar esta instruccion, incialmente todas las conexiones podran asignar threads trabajadores, pero los threads asociados con master1 necesitara esperar hasta que la instruccion que llevara mucho tiempo de ejecucion haya finalizado, cuando no haya mas threads trabajadores libres las otras conexiones ya no podran beneficiarse de la replicacion paralela
• @@slave_domain_parallel_threads tiene como proposito evitar que una conexion de amo sola monopolice el pool de threads, este valor determina el numero maximo de threads que pueden ser ubicadas por la misma conexion maestra, si este valor no es menor que @@slave_parallel_threads no tiene efecto pero si es menor que @@slave_parallel_threads divido por el numero de conexiones maestras ocasionara que algunos threads nunca seran usados, por esta razon el valor deberia dejarse lo mas alto posible para evitar que una conexion maestra asigne un thread cuando no sea necesario

En la vida real encontrar un valor optimo para la variable @@slave_parallel_threads es muy dificil de encontrar, es altamente dependiente de las cargas de trabajo del amo, por esto como regla general se inicia al servidor con un valor que sea considerablemente mas bajo que @@slave_parallel_threads y luego bajar mas valor en caso de que ocurra un error cuando se ejecutan instruccion de larga ejecucion, todas estas variables son dinamicas con lo cual modificar la configuracion de la replicacion paralela no requieren que se reinicie el amo sin embargo si se deberia detener temporalmente a los esclavos.

En resumen, hoy hemos hablado sobre la replicacion paralela, que es, como trabaja, cuales son las variables principales para poder configurarlo y una buena practica para el uso correcto, 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.