¿Qué es la Alta disponibilidad de MySQL?

La Alta disponibilidad de MySQL es una opción que se puede seleccionar para permitir que su base de datos de MySQL siga estando disponible en caso de que se produzca un fallo o una interrupción. Esta característica le permite establecer unos requisitos mayores de tiempo de actividad y una tolerancia cero a la pérdida de datos. En este artículo, veremos el significado del concepto general de alta disponibilidad y cómo funciona la opción de Alta disponibilidad de MySQL. 

¿Qué es la alta disponibilidad?

La alta disponibilidad es la capacidad de un sistema o servicio de continuar funcionando o de seguir estando disponible cuando se produce un fallo o una interrupción. Un sistema de alta disponibilidad garantiza que los sistemas y las aplicaciones de misión crítica de una organización estén siempre listos y en funcionamiento. Es especialmente importante para las organizaciones de sectores como la sanidad, las finanzas y la aviación, donde un fallo en un sistema de misión crítica puede tener consecuencias graves.

La alta disponibilidad se suele expresar como un porcentaje del tiempo de actividad definido por los acuerdos de nivel de servicio (SLA), donde un resultado de 100 representa un sistema que no falla nunca. Como es prácticamente inalcanzable, la mayoría de las organizaciones aspiran a tener una disponibilidad de “cinco nueves”, es decir, del 99,999%.

¿Cómo se consigue la alta disponibilidad en MySQL?

Un sistema de alta disponibilidad tiene que ser capaz de recuperarse al instante si se produce un error. Una arquitectura de alta disponibilidad exige que al menos tres elementos básicos funcionen conjuntamente para garantizar la recuperabilidad y la alta disponibilidad.

Detección de fallos

MySQL tiene una opción de Alta disponibilidad que permite que las aplicaciones cumplan los requisitos de un mayor tiempo de actividad (y de tolerancia cero a la pérdida de datos). Cuando la opción de Alta disponibilidad está activada, el sistema MySQL crea tres instancias en diferentes dominios de error o zonas de disponibilidad.

Los datos se replican en las tres instancias, usando la Replicación de grupo de MySQL y la aplicación se conecta a la instancia principal para leer y escribir los datos en y desde la base de datos. Si se produce un fallo, el sistema activa una conmutación por error automática a una instancia secundaria en unos minutos.

Conmutación por error

El mecanismo de conmutación por error transfiere los servicios a una instancia replicada. Si hay más de una instancia de copia de seguridad disponible, el mecanismo de conmutación por error elige la mejor para convertirla en el nodo principal. 

Un mecanismo de redireccionamiento

Una vez que se ha producido la conmutación por error a una instancia secundaria, la funcionalidad de Alta disponibilidad redirige todas las conexiones de aplicación y de usuario a lo que ahora es el nuevo nodo principal. Y también redirige todas las consultas desde el antiguo nodo principal hasta la nueva base de datos principal. 

Alta disponibilidad de MySQL: tiempo de actividad

El tiempo de actividad es el tiempo durante el cual un sistema está disponible y funciona correctamente y se expresa como un porcentaje del tiempo total que se espera que el sistema esté operativo. Un tiempo de actividad elevado significa que el sistema está disponible y que funciona tal como se espera la mayor parte del tiempo. 

El tiempo de actividad que puede esperar con los diferentes niveles de Alta disponibilidad de MySQL dependerá de la solución de alta disponibilidad (HA por sus siglas en inglés) concreta que implemente.

La Replicación de MySQL

La Replicación de MySQL le permite configurar múltiples servidores para que proporcionen redundancia y conmutación por error, para lograr unos tiempos de actividad mayores que los de un servidor de MySQL sin función de Alta disponibilidad. Una configuración de maestro/esclavo utiliza un único servidor maestro que acepta lecturas y escrituras y uno o más servidores esclavos de solo lectura. Los datos del servidor maestro se replican de forma asincrónica en los servidores esclavos.

Para implementar la conmutación por error, tendrá que configurar uno o más servidores esclavos como servidores en espera que se pueden promocionar a servidor maestro en caso de fallo. La conmutación por error suele ser un proceso manual en el que hay que promocionar el nodo esclavo a nodo maestro, cambiando el estado del nodo esclavo promocionado y pasándolo al modo de lectura-escritura, para que pueda aceptar solicitudes.

Como la conmutación por error se realiza manualmente, tarda más tiempo y es más propensa a los errores humanos, lo que genera unos tiempos de interrupción más largos. La Replicación de MySQL también usa la replicación asincrónica, lo que significa que si el maestro falla, es posible que las transacciones confirmadas en el maestro todavía no se hayan replicado en los servidores esclavos. Si hay una pérdida de datos críticos, es necesario restaurar los datos, lo que prolonga el plazo de tiempo que el sistema está fuera de servicio.

La Replicación de grupo de MySQL

La Replicación de grupo de MySQL le permite lograr unos tiempos de actividad más elevados que la Replicación de MySQL. Con la Replicación de grupo de MySQL, configura múltiples servidores de MySQL en un grupo, de manera que uno de ellos es designado como servidor principal y los otros como servidores secundarios. Cada servidor del grupo conserva una copia de los datos y utiliza la replicación para garantizar que las copias se mantienen sincronizadas. 

Si el servidor principal queda fuera de servicio, los servidores secundarios del grupo detectan automáticamente el fallo e inician el proceso de conmutación por error. Uno de los servidores secundarios es promocionado automáticamente a nuevo servidor principal y empieza a atender las solicitudes de los clientes. Los otros miembros secundarios del grupo reciben ahora las actualizaciones del nuevo servidor principal y siguen procesando las solicitudes de lectura de los clientes.

Si el servidor que ha fallado vuelve a estar en línea, se une automáticamente al grupo como servidor secundario.

Como la detección del fallo y la conmutación por error se producen automáticamente con la Replicación de grupo de MySQL, el tiempo de inactividad es mínimo y los usuarios y las aplicaciones normalmente no detectan que se ha producido una interrupción. 

El Clúster de MySQL

Una solución de alta disponibilidad de Clúster de MySQL ofrece el mayor nivel de tiempo de actividad. Este sistema de base de datos distribuida de alta disponibilidad, junto con la conmutación por error automática y el equilibrio de carga, ofrece unos elevados niveles de disponibilidad, rendimiento y escalabilidad y está diseñado para proporcionar un tiempo de inactividad cercano a cero. 

El Clúster de MySQL usa tres tipos de nodos que funcionan conjuntamente para almacenar y administrar los datos:

• Nodos de datos: almacenan los datos y manejan las solicitudes de lectura y escritura.
• Nodos de servidor de MySQL: reciben las solicitudes de las aplicaciones cliente, las procesan en los nodos de datos y luego devuelven el resultado a los clientes.
• Nodos de administración: gestionan el funcionamiento del clúster y se encargan de la conmutación por error y la recuperación si se produce un fallo.

Si uno o más nodos de un clúster fallan, el clúster detecta automáticamente el problema y pone en marcha el proceso de conmutación por error. Todo el proceso suele desarrollarse en un segundo como máximo, tras el fallo, sin interrumpir el servicio a las aplicaciones cliente. El clúster sigue funcionando con normalidad, prácticamente sin tiempo de inactividad.

Alta disponibilidad de MySQL: tiempo de recuperación 

El tiempo de recuperación es la medida del tiempo que un sistema MySQL tarda en recuperarse de una interrupción. Un tiempo de recuperación más largo provoca una menor disponibilidad y puede afectar directamente a la capacidad de la empresa para generar ingresos, la productividad de los empleados y la satisfacción de los clientes.

En MySQL, los tiempos de recuperación varían en función del tipo de replicación que se use:

• Los tiempos de recuperación de la Replicación de MySQL para la replicación maestro-esclavo se verán afectados por el proceso manual de conmutación por error. Después de promocionar el servidor esclavo a nuevo nodo primario, tendrá que reiniciarlo para que pueda empezar a replicar los datos en los servidores esclavos restantes. Luego, deberá tener en cuenta las transacciones que faltan y resolver cualquier conflicto que pueda darse.
• La Replicación de grupo usa un proceso automático de detección de fallos y conmutación por error que reduce los tiempos de recuperación respecto de la replicación maestro-esclavo. Los mecanismos de detección y resolución de conflictos garantizan que los datos de cada servidor estén siempre sincronizados entre todos los servidores del grupo. La Replicación en grupo también utiliza unos tipos de datos replicados sin conflictos (CRDT por sus siglas en inglés), para conciliar los datos automáticamente cuando se produce un conflicto. Con la Replicación en grupo, el sistema puede recuperarse de un fallo con muy poco tiempo de inactividad.
• El Clúster de MySQL utiliza un enfoque “sin compartición”, en el que cada nodo del clúster tiene asignados una memoria y un almacenamiento en disco propios y se comunica con los otros nodos mediante una conexión de alta velocidad. El Clúster de MySQL sigue funcionando aunque fallen uno o más nodos. El clúster detecta automáticamente el problema y pone en marcha el proceso de conmutación por error, para recuperarse prácticamente sin tiempo de inactividad.

Cómo determinar sus requisitos de alta disponibilidad de MySQL

Para determinar sus requisitos de Alta disponibilidad de MySQL, deberá tener en cuenta varios factores, como:

• Su arquitectura de sistema actual: ¿qué componentes tiene actualmente su sistema y cómo están configurados? ¿Pueden admitir la Alta disponibilidad de MySQL?
• El presupuesto: ¿cuánto deberá gastar en recursos como hardware, software y personal? También debe tener en cuenta los costes asociados con la formación y el mantenimiento constante.
• Las necesidades de la empresa: considere sus objetivos de tiempo de recuperación (RTO) y sus objetivos de punto de recuperación (RPO). ¿Cuál es su tiempo de recuperación ideal? ¿Con qué rapidez necesita recuperarse de un fallo? Tenga también en cuenta si su organización está sujeta a algún requisito regulatorio o de cumplimiento normativo que exija una alta disponibilidad.
• El nivel de importancia de los datos: ¿en qué medida son críticos los datos para su empresa? ¿Cuál es la importancia de mantenerlos actualizados? ¿Cuántos datos puede permitirse perder?

Cuándo usar la Alta disponibilidad de MySQL

Veamos un par de casos de uso que necesitan soluciones de Alta disponibilidad de MySQL:

Sitios web con un tráfico elevado

Los sitios web con un tráfico elevado manejan miles de solicitudes y transacciones por segundo, por no hablar de sus miles de usuarios simultáneos. Medidas de la alta disponibilidad como la redundancia del servidor y el equilibrio de carga pueden garantizar que la base de datos siga estando disponible y pueda manejar la carga. 

Los servidores redundantes garantizarán que el sitio web se mantiene disponible aunque se produzca un fallo, mientras que el equilibrio de la carga de las solicitudes entrantes entre múltiples servidores impedirá que un solo servidor se sobrecargue y se desconecte.

Aplicaciones y cargas de trabajo de misión crítica

Las empresas con sistemas y aplicaciones de misión crítica necesitan un alto nivel de disponibilidad y tiempo de actividad. La mayoría de las veces, estos sistemas no pueden permitirse sufrir ningún tiempo de inactividad y las bases de datos tienen que estar disponibles en todo momento. 

Las soluciones de alta disponibilidad de MySQL, como la Replicación de grupo y el Clúster, son ideales en este caso de uso, porque emplean un mecanismo de conmutación por error automático que permite que el tiempo de inactividad sea mínimo o inexistente.

¿Cómo permite Pure Storage la Alta disponibilidad de MySQL?

Evergreen™ de Pure Storage® es una cartera de suscripciones que ofrecen unas  implementaciones sin tiempos de inactividad. Combinada con la arquitectura única de la cabina de almacenamiento de Pure Storage, Evergreen le permite actualizar la infraestructura de almacenamiento sin interrumpir las cargas de trabajo del servicio. 

Pure también admite la agrupación en clústeres en modo activo-activo y la conmutación por error transparente automática con Purity ActiveCluster™, un clúster extendido activo-activo multisitio, para unos RPO y unos RTO de cero.

Piense también en Pure Cloud Block Store™, que proporciona una fiabilidad de nube de nivel empresarial para las aplicaciones de misión crítica. Las actualizaciones no disruptivas y la alta disponibilidad en las zonas de disponibilidad consiguen ofrecer una alta disponibilidad para la recuperación ante desastres y la continuidad operativa multinube.