Qué hacemos · Datos y web: Bases de datos en clúster con Percona XtraDB Cluster
Su aplicación habla con una base de datos, pero detrás hay tres copias síncronas, cada una en hardware separado. Una escritura confirmada existe en todos los nodos antes de que su aplicación oiga «OK», de modo que perder un servidor, parchearlo o reiniciarlo es trabajo de rutina, no una interrupción.
Qué es
Percona XtraDB Cluster es compatible con MySQL y está construido sobre la replicación síncrona de Galera. Su aplicación en WordPress, Magento, PrestaShop, Laravel o PHP a medida sigue hablando MySQL normal. Lo que cambia está debajo: ya no queda un único servidor de base de datos cuyo fallo se lleve consigo todo el sitio.
Combinamos el clúster con ProxySQL, que envía las escrituras a un nodo elegido y reparte las lecturas entre todos. La aplicación no necesita cambios ni conocer la topología.
Cómo lo construimos
- Tres nodos, tres dominios de fallo. Cada nodo se ejecuta en su propio blade o máquina virtual y, donde la plataforma lo permite, cada uno arranca y guarda sus datos en una cabina de storage distinta. Un fallo de host o de cabina cuesta una réplica, nunca el quorum.
- ProxySQL como sidecar local en cada nodo web. No hay un balanceador de base de datos compartido que se convierta en el siguiente punto único de fallo. El monitor de salud de ProxySQL, consciente de Galera, sigue el estado del clúster y, si el writer cae, promueve uno nuevo en segundos.
- Lecturas causales para los editores. Activamos comprobaciones de lectura síncronas para que un editor que guarda en un nodo y recarga desde otro vea siempre su propio cambio. Ningún ticket de «mi artículo ha desaparecido».
- Margen para reincorporarse. La caché de write sets está dimensionada para que un nodo pueda estar fuera durante horas de mantenimiento y volver de forma incremental, en lugar de copiar de nuevo todo el conjunto de datos.
- Backups cada treinta minutos. Percona XtraBackup toma backups físicos consistentes en caliente, que se comprimen y se traen por pull a un host de backup separado. El lado de producción nunca hace push hacia la infraestructura de backup.
- Vigilado de forma continua. Cada nodo está en Percona Monitoring and Management.
En OpenShift rigen las mismas reglas
Cuando la base de datos se ejecuta en OpenShift u OKD, lo hace como un StatefulSet con anti-affinity estricta entre chasis y con un PodDisruptionBudget que mantiene el quorum intacto. Un reinicio escalonado de nodos por una actualización de la plataforma nunca puede así tirar más de un miembro de la base de datos a la vez. Ese es el estándar de diseño con el que construimos en toda plataforma de contenedores, no un extra opcional.
De qué le protege
- La interrupción clásica: todo el sitio caído porque el único servidor MySQL está caído.
- Tormentas de deadlocks por escribir en todos los nodos a la vez, que los esquemas round robin ingenuos producen bajo carga de WordPress y de plugins de e-commerce.
- Editores que pierden un guardado porque su siguiente lectura cayó en un nodo que aún no lo había aplicado.
- Ventanas de mantenimiento por actualizaciones de kernel, parches de base de datos y trabajos de hardware.
- Una cabina de storage o un chasis que se lleva consigo la base de datos.
- Una rolling update de Kubernetes que rompe el quorum en silencio.
En la práctica
Una plataforma de analítica. Para la plataforma de analítica y transacciones de un cliente construimos el nivel transaccional sobre Percona XtraDB Cluster con ProxySQL y una dirección flotante. Antes de la entrega retiramos el writer a propósito; ProxySQL movió las escrituras a un nodo superviviente y la aplicación siguió funcionando.
Por qué EuroVPS
- Diseñamos los dominios de fallo, no solo el clúster: hosts distintos, cabinas distintas, chasis distintos.
- Ningún proxy de base de datos compartido en medio. Cada nodo web enruta sus propias consultas.
- Los backups son físicos, frecuentes y los trae por pull el lado de backup, nunca los empuja producción.
- Probamos el failover antes de la entrega, con la aplicación del cliente funcionando sobre él.
- La misma disciplina en máquinas virtuales, bare metal y OpenShift.
Preguntas frecuentes
- ¿Tenemos que cambiar nuestra aplicación? No. ProxySQL presenta un endpoint MySQL normal. Las aplicaciones que escriben en tablas no transaccionales o dependen de bloqueos poco habituales se revisan primero con usted.
- ¿Es compatible con MySQL o con MariaDB? Percona XtraDB Cluster es un servidor compatible con MySQL. Migramos bases de datos MySQL y MariaDB a él y comprobamos juegos de caracteres, plugins de autenticación y modos SQL durante la migración.
- ¿La replicación síncrona de tres nodos hace más lentas las escrituras? Cada commit espera a que los demás nodos lo certifiquen, así que la latencia entre nodos importa. Por eso todos los miembros están en el mismo fabric de baja latencia en un datacenter, y las copias offsite las llevan réplicas asíncronas.
- ¿Podemos ejecutarlo dentro de OpenShift? Sí, como StatefulSet con anti-affinity entre chasis y un PodDisruptionBudget, que es nuestro estándar para cualquier base de datos basada en quorum sobre Kubernetes.
- ¿Qué ocurre durante el fallo de un nodo? Los nodos supervivientes mantienen el quorum y siguen sirviendo. ProxySQL enruta esquivando el nodo ausente y, cuando vuelve, se pone al día de forma incremental.
¿Quiere una base de datos que soporte la pérdida de un servidor? Hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.