Los proyectos que gestionamos para nuestros clientes son muy diversos. Hay clientes que saben que siempre tendrán suficiente con un servidor de datos para toda la vida. Los hay que, debido a su previsión de crecimiento, nos plantean montar un sistema Master-Slave, con el fin de crecer en el futuro si las necesidades apretasen. Y los hay que no prevén un crecimiento futuro pero finalmente sí lo tienen. Entonces, hay que correr para modificar el comportamiento de un servidor de datos desde Stand-Alone a Master y colocarle al lado un Slave que absorba el alto impacto de las consultas de lectura. Para poder caminar sobre seguro, sea cual sea el rendimiento que esperas de tu plataforma, ICM ha desarrollado un sistema de replicación de datos síncrono (Fast Data Replication)
¿Qué es el Fast Data Replication?
Este sistema de replicación de datos síncrono está apoyado en un sistema Master-Master y todo montado sobre N balanceadores de carga. De esta forma minimizamos el tiempo de caída de la plataforma y aumentamos el rendimiento de la aplicación. Así, el desarrollador ya no está obligado a ahogar a un Master con miles de queries modificantes (por ejemplo, los típicos INSERT o UPDATE)
Asimismo, los Slaves se llenan de queries no modificantes (SELECT). Este montaje podía ser poco eficiente, puesto que un proyecto con pocos INSERTS, por ejemplo, desaprovecharía la potencia del Master. Mientras que un proyecto que abusase de ese tipo de queries, desaprovecharía la potencia del Slave para procesar peticiones. Además, el desarrollador, debía escribir código específico para redirigir los SELECTS al Slave y los INSERTS al Master, en el caso más simplista que uso a modo de ejemplo.
Beneficios del FDR
Con nuestro sistema FDR, el desarrollador escribirá su código de la misma forma que siempre. Su conexión apuntará a una única IP y ejecutará indistintamente SELECTS o INSERTS sobre esa IP, sin importarle dónde termina ejecutándose esa query.
Esa IP, que será la “cara visible” de una red de balanceadores, se encargará de redireccionar la conexión contra unos de los nodos finales. Independientemente, de dónde acabará puesto que, acabe donde acabe, nuestro sistema FDR replicará los datos a través de toda la red de bases de datos.
¿Crecer? ¡Claro! Sólo hay que añadir un nuevo servidor de bases de datos limpio al Pool de servidores que manejarán los balanceadores. Sin caída, sin perdidas de datos, sin problemas para nuestros clientes.
¿Reducir? ¡También! Es tan sencillo como dar de baja del balanceador los servidores que, por simas (ojo, no picos) de tráfico, ya no necesita tanta potencia dedicada a sus bases de datos. De hecho, podríamos apagar N -1 servidores de base de datos, siendo N el total de servidores que nuestro cliente ha solicitado, y no perderíamos un solo dato. Ni siquiera notaríamos una ligera incidencia en la continuidad del servicio.