Configuración explicada de MySQL en Hostinger

En Hostinger, tenemos varias configuraciones de MySQL, desde las instancias independientes sin réplica hasta Percona XtraDB Cluster (más tarde solo PXC), soluciones basadas en enrutamiento ProxySQL e incluso absolutamente personalizadas y únicas que describimos en esta publicación.

No tenemos bases de datos del tamaño de un elefante para servicios internos como API, facturación y clientes. Por lo tanto, casi todas las decisiones terminan con la alta disponibilidad como máxima prioridad en lugar de la escalabilidad.

Aún así, escalar verticalmente es lo suficientemente bueno para nuestro caso, ya que el tamaño de la base de datos no supera los 500 GB. Uno de los requisitos principales es la capacidad de acceder al nodo principal, ya que tenemos cargas de trabajo de lectura y escritura bastante distantes.

Nuestra configuración actual para almacenar todos los datos de los clientes, servidores, etc. utiliza PXC formado por tres nodos sin ninguna replicación geográfica. Todos los nodos se ejecutan en el mismo centro de datos.

Tenemos planes de migrar este clúster a un clúster replicado geográficamente en tres ubicaciones: Estados Unidos, Holanda y Singapur. Esto nos permitiría garantizar una alta disponibilidad si una de las ubicaciones se volviera inaccesible.

Dado que PXC utiliza la replicación completamente sincrónica, habrá latencias más altas para las escrituras. Pero las lecturas serán mucho más rápidas debido a la réplica local en cada ubicación.

Investigamos un poco sobre la replicación de grupos de MySQL, pero requiere que las instancias estén más cerca unas de otras y es más sensible a las latencias.

La replicación de grupo está diseñada para implementarse en un entorno de clúster donde las instancias de servidor están muy cerca unas de otras y se ve afectada tanto por la latencia de la red como por el ancho de banda de la red.

Utilizamos PXC anteriormente, por lo que sabemos cómo tratarlo en circunstancias críticas y hacerlo más disponible.

En el proyecto 000webhost.com y hAPI (API de Hostinger) utilizamos nuestra solución única antes mencionada que selecciona el nodo maestro utilizando el protocolo Layer3.

Uno de nuestros mejores amigos es el protocolo BGP y BGP, que tiene la edad suficiente para comprar su propia cerveza, por lo que lo usamos mucho. Esta implementación también usa BGP como protocolo subyacente y ayuda a apuntar al nodo maestro real. Para ejecutar el protocolo BGP usamos el servicio ExaBGP y anunciamos la dirección VIP como anycast desde ambos nodos maestros.

Te estarás preguntado: ¿pero cómo están seguros de que las consultas de MySQL van a la misma instancia en lugar de a ambas? Usamos los nodos efímeros de Zookeeper para adquirir el bloqueo como mutuamente excluyente.

Zookeeper actúa como un disyuntor entre los speakers de BGP y los clientes MySQL. Si se aplica el bloqueo, anunciamos el VIP desde el nodo maestro y las aplicaciones envían las consultas hacia esta ruta. Si se libera el bloqueo, otro nodo puede tomar el control y anunciar el VIP, por lo que la aplicación enviará las consultas sin ningún esfuerzo.

Surge la segunda pregunta: ¿qué condiciones se deben cumplir para dejar de anunciar VIP? Esto se puede implementar de manera diferente según el caso de uso, pero liberamos el bloqueo si el proceso de MySQL está inactivo utilizando Requires de Systemd en el archivo de unidad de ExaBGP.

Además, con o sin especificar After=, esta unidad se detendrá si una de las otras unidades se detiene explícitamente.

Con systemd podemos crear un bonito árbol de dependencias que garantice que se cumplan todas. Detener, terminar o incluso reiniciar MySQL hará que systemd detenga el proceso ExaBGP y retire el anuncio VIP. El resultado final es un nuevo master seleccionado.

Probamos todo esto en batalla durante nuestros días de ensayos y aún no hemos notado nada crítico.

Si crees que la buena arquitectura es cara, prueba la mala arquitectura. ?