En este documento, se describen varias arquitecturas que proporcionan alta disponibilidad (HA) para las implementaciones de MySQL en Google Cloud. La HA es la medida de la resiliencia del sistema en respuesta a una falla de la infraestructura subyacente. En este documento, la HA aborda la disponibilidad de los clústeres de MySQL dentro de una región de una sola nube.
Este documento está dirigido a los administradores de bases de datos, los arquitectos de la nube y los ingenieros DevOps que desean aprender a aumentar la confiabilidad a nivel de datos de MySQL mediante la mejora del tiempo de actividad general del sistema. Si ejecutas MySQL en Compute Engine, este documento está pensado para ti. Si usas Cloud SQL para MySQL, este documento no está pensado para ti.
En el caso de un sistema o una aplicación que requiere un estado persistente con el fin de manejar las solicitudes o las transacciones, la capa de persistencia de los datos debe estar disponible para manejar con éxito las solicitudes de mutaciones o consultas de datos. Si la aplicación debe interactuar con el nivel de datos de las solicitudes de servicio, cualquier tiempo de inactividad que surja en el nivel de datos impide que la aplicación realice las tareas necesarias.
En función de los objetivos de nivel de servicio (SLO) del sistema, puede que necesites una topología de arquitectura que proporcione un nivel de disponibilidad más alto. Hay más de una forma de lograr HA. Pero, en general, debes aprovisionar una infraestructura redundante en la que puedas habilitar el acceso para tu aplicación con rapidez.
En este documento, se analizan los siguientes temas:
- Define términos para ayudarte a comprender los conceptos de la base de datos de HA.
- Obtén ayuda para comprender varias opciones de las topologías de MySQL de HA.
- Proporciona información contextual que te ayude a comprender qué tener en cuenta en cada opción.
Terminología
Existen varios términos y conceptos que son estándares de la industria, y es útil comprenderlos por razones que están fuera del alcance de este documento.
Replicación. Es el proceso mediante el cual las transacciones de escritura (INSERT, UPDATE o DELETE) se capturan, registran y aplican en serie de forma confiable en todos los nodos de la base de datos de la topología.
Nodo fuente. Todas las escrituras de la base de datos deben dirigirse a un nodo fuente. El nodo fuente proporciona una lectura con el estado más actualizado de los datos persistentes.
Nodo de réplica. Es una copia en línea del nodo de la base de datos fuente. Los cambios se replican de forma casi síncrona en los nodos de réplica desde el nodo fuente. Puedes leer desde los nodos de réplica, pero debes tener en cuenta que los datos podrían estar un poco retrasados debido al retraso de la replicación.
Retraso de la replicación. Es una medida de tiempo que expresa la diferencia entre el momento en que se aplica una transacción en la réplica y el momento en que se aplica en el nodo fuente.
Tiempo de actividad. Es el porcentaje de tiempo en que un recurso se encuentra en funcionamiento y puede entregar una respuesta a una solicitud.
Detección de fallos. Es el proceso con el que se identifica que se produjo un error en la infraestructura.
Conmutación por error. Es el proceso que consiste en promover la infraestructura de copia de seguridad o en espera (en este caso, el nodo de réplica) para que se convierta en la infraestructura principal. En otras palabras, durante una conmutación por error, el nodo de réplica se convierte en el nodo fuente.
Objetivo de tiempo de recuperación (RTO). Es la duración aceptable, en el tiempo real transcurrido, desde una perspectiva empresarial, para que se complete el proceso de conmutación por error del nivel de datos.
Resguardo. Es el proceso de restablecimiento del nodo fuente anterior luego de que se produce una conmutación por error.
Autorreparación. Es la capacidad que tiene un sistema de resolver problemas sin necesidad de que un operador humano realice acciones externas.
Partición de red. Es una condición en la que dos nodos de una topología, por ejemplo, los nodos fuente y de réplica, no pueden comunicarse entre sí en la red.
Cerebro dividido. Es una condición que ocurre cuando dos nodos creen de forma simultánea que son el nodo fuente.
Grupo de nodos. Es un conjunto de tareas de recursos de procesamiento que proporcionan un servicio. En este documento, ese servicio es el nivel de persistencia de los datos.
Nodo testigo o de quórum. Es un recurso de procesamiento independiente que ayuda a un grupo de nodos a determinar qué hacer cuando surge una condición de cerebro dividido.
Elección de líder o fuente. Es el proceso mediante el cual un grupo de nodos adaptados al intercambio de tráfico, incluidos los nodos testigo, determina cuál nodo debe ser la fuente.
Grupo de nodos. Es un conjunto de tareas de recursos de procesamiento que proporcionan un servicio. En este documento, ese servicio es el nivel de persistencia de los datos.
Espera activa. Un nodo que representa una copia cercana de otro nodo fuente y puede convertirse en el nuevo nodo fuente con un tiempo de inactividad mínimo.
Cuándo considerar el uso de una arquitectura de HA
Las arquitecturas de HA proporcionan una mayor protección contra el tiempo de inactividad a nivel de datos. Comprender la tolerancia al tiempo de inactividad y las compensaciones respectivas de las diferentes arquitecturas es fundamental a la hora de elegir la opción adecuada para el caso de uso empresarial.
Usa una topología de HA cuando quieras proporcionar un mayor tiempo de actividad a nivel de datos para cumplir con los requisitos de confiabilidad de las cargas de trabajo y los servicios. En el caso de los entornos en los que se tolera una cierta cantidad de tiempo de inactividad, una topología de HA presenta un costo y una complejidad innecesarios. Por ejemplo, es poco frecuente que los entornos de desarrollo o de pruebas necesiten alta disponibilidad a nivel de base de datos.
Considera tus requisitos para la HA
El costo es una cuestión importante, ya que, para proporcionar HA, debes esperar que los costos del almacenamiento y de infraestructura de procesamiento sean de, al menos, el doble. Cuando evalúes las posibles opciones de HA de MySQL, ten en cuenta las siguientes preguntas:
- ¿Qué servicios o clientes dependen de tu nivel de datos?
- ¿Cuál es tu presupuesto operativo?
- ¿Cuál es el costo para tu empresa en el caso de que haya tiempo de inactividad en el nivel de persistencia de los datos?
- ¿Qué tan automatizado debe ser el proceso?
- ¿Qué nivel de disponibilidad esperas alcanzar? ¿El 99.5%, el 99.9% o el 99.99%?
- ¿Qué tan rápido debes realizar la conmutación por error? ¿Cuál es tu RTO?
Los siguientes factores contribuyen al tiempo de recuperación y deben tenerse en cuenta cuando se establece el RTO:
- La detección de la interrupción
- La preparación de la instancia de máquina virtual (VM) secundaria
- La conmutación por error del almacenamiento
- El tiempo de recuperación de la base de datos
- El tiempo de recuperación de la aplicación
Arquitecturas de HA de MySQL
En el nivel más básico, la HA en el nivel de datos consta de los siguientes elementos:
- Un mecanismo para identificar que se produjo un error en el nodo fuente
- Un proceso para realizar una conmutación por error en la que el nodo de réplica ascienda a nodo fuente
- Un proceso para cambiar el enrutamiento de la consulta de forma que las solicitudes de la aplicación lleguen al nodo fuente nuevo
- De forma opcional, un método para regresar a la topología original mediante el uso de los nodos fuente y de réplica
En este documento, se analizan las siguientes tres arquitecturas de HA:
Además de solucionar el error en la infraestructura, cada una de estas arquitecturas te puede ayudar a minimizar el tiempo de inactividad en el caso improbable de una interrupción zonal. Debes usar estas arquitecturas con cambios en el sistema de nombres de dominio (DNS) a fin de proporcionar HA multiregional para protegerte contra la interrupción regional del servicio. Sin embargo, este tema está fuera del alcance de este documento.
HA con discos persistentes regionales
La HA en el nivel de datos siempre depende de algún tipo de replicación de datos. La replicación más simple es aquella que no necesitas administrar.
Con la opción de almacenamiento en el disco persistente regional de Compute Engine, puedes aprovisionar un dispositivo de almacenamiento en bloque que proporcione una replicación de datos síncrona entre dos zonas de una región. Los discos persistentes regionales proporcionan un componente básico que es fundamental y sólido para la implementación de servicios de HA en Compute Engine.
En el siguiente diagrama, se ilustra la arquitectura de HA en la que se usan discos persistentes regionales.
Si la instancia de VM del nodo fuente deja de estar disponible debido a un error en la infraestructura o a una interrupción zonal, puedes forzar la conexión del disco persistente regional a una instancia de VM en la zona de copia de seguridad en la misma región.
Para llevar a cabo esta tarea, debes realizar una de las siguientes acciones:
- Inicia otra instancia de VM en la zona de la copia de seguridad en la que el acceso al disco persistente regional compartido esté disponible.
- Mantén una instancia de VM en espera activa en la zona de la copia de seguridad. Una instancia de VM en espera activa es una instancia de VM en ejecución que es idéntica a la instancia que usas. Después de conectar el disco persistente regional, puedes iniciar el motor de base de datos.
Si la interrupción del servicio de datos se identifica con rapidez, la operación de conexión forzada se completa en menos de un minuto, lo que significa que se puede lograr un RTO medido en minutos.
Si la empresa puede tolerar el tiempo de inactividad adicional que es necesario para detectar una interrupción y comunicarla, y realizar la conmutación por error de forma manual, no es necesario automatizar el proceso.
Si la tolerancia del RTO es más baja, puedes automatizar el proceso de detección y conmutación por error. Si automatizas esta arquitectura, el sistema se complicará aún más, ya que existen varios casos extremos en el proceso de resguardo y conmutación por error que debes tener en cuenta. Para obtener más información sobre una implementación de esta arquitectura que está automatizada por completo, consulta la configuración de alta disponibilidad en Cloud SQL.
Ventajas
Existen varias ventajas de lograr HA mediante el uso de discos persistentes regionales debido a las siguientes características:
- Esta arquitectura proporciona protección simultánea contra varios modos de errores: el error en la infraestructura del servidor de la zona principal, la degradación del almacenamiento en bloque de una sola zona o la interrupción en toda una zona.
- La replicación de la capa de la aplicación o la base de datos no es necesaria porque los discos persistentes regionales proporcionan una replicación de datos continua y síncrona a nivel de bloque, que Google Cloud administra por completo. De forma automática, un disco persistente regional detecta los errores y la lentitud, cambia el modo de replicación y realiza la actualización de los datos replicados solo en una zona.
- Si hay problemas de almacenamiento en una zona principal, un disco persistente regional realiza lecturas desde la zona secundaria de forma automática. Esta operación puede tener como resultado una mayor latencia de lectura, pero la aplicación puede seguir funcionando sin ninguna acción manual.
Consideraciones
Las limitaciones de esta arquitectura están relacionadas con el carácter de una sola región de esta topología y con algunas de las siguientes restricciones inherentes de los discos persistentes regionales:
- El disco persistente regional solo se puede activar en una base de datos. Incluso si la instancia de VM de la base de datos en espera se encuentra en ejecución, no se puede usar para entregar lecturas de la base de datos.
- La tecnología básica subyacente a esta arquitectura solo permite la replicación entre zonas de la misma región. Como resultado, la conmutación por error regional no es una opción cuando se usa solo esta arquitectura.
- La capacidad de procesamiento de escritura del disco persistente regional se redujo a la mitad en comparación con la de los discos persistentes zonales. Asegúrate de que los límites de la capacidad de procesamiento estén dentro de la tolerancia requerida.
- La latencia de escritura del disco persistente regional es ligeramente mayor que la del disco persistente zonal. Te recomendamos probar la carga de trabajo con el fin de verificar que el rendimiento de la escritura sea aceptable para tus requisitos.
- Durante un evento de falla y la migración de sistemas resultante, debes forzar la conexión del disco persistente regional a la VM de la zona en espera. Por lo general, la operación de conexión forzada se ejecuta en menos de un minuto, por lo que debes considerar este tiempo cuando evalúes el RTO.
- En la estimación del RTO, se debe tener en cuenta el tiempo necesario para la conexión forzada del disco persistente regional y la detección del sistema de archivos de VM del disco conectado en caliente.
HA con un nodo testigo y en espera activa
Si deseas obtener una conmutación por error automatizada, se necesita una arquitectura diferente. Una opción consiste en implementar un grupo de al menos dos nodos de bases de datos, configurar la replicación asíncrona de la base de datos y, luego, iniciar nodos testigo para garantizar que se pueda llegar a un quórum durante la elección de un nodo fuente.
El nodo de la base de datos fuente procesa las transacciones de escritura y entrega las consultas de lectura. En el proceso de replicación de la base de datos, se transmiten los cambios al nodo de réplica en espera activa en línea.
Como el nodo testigo puede ser una máquina virtual pequeña, proporciona un mecanismo de bajo costo destinado a garantizar que la mayor parte del grupo esté disponible para la elección de un nodo fuente.
Los nodos del grupo evalúan el estado de los otros nodos del grupo de forma continua. Las señales que estas verificaciones de estado consumen cada pocos segundos se denominan señales de monitoreo de funcionamiento, ya que se usan para evaluar el estado de los demás nodos del grupo. Es importante realizar una evaluación oportuna del estado de los nodos de la base de datos porque, si un nodo de la base de datos fuente se encuentra en mal estado, se debe identificar con rapidez para que se pueda iniciar una conmutación por error del nodo en espera activa.
El quórum del grupo de nodos está determinado por la cantidad de elementos votantes que deben ser parte de la membresía del clúster activo para que comience a ejecutarse de forma adecuada o se siga ejecutando. Para que un grupo de nodos llegue a un quórum en la elección de un nodo de la base de datos fuente, deben participar la mayoría de los nodos del grupo. Para protegerte contra una condición de cerebro dividido, el requisito de mayoría garantiza que, en el caso de una partición de red, dos grupos votantes no puedan tener suficientes nodos para votar a la vez.
Una mayoría de grupo está compuesta por (n+1)/2 nodos. Aquí, n es la cantidad total de nodos en el grupo. Por ejemplo, si hay tres nodos en un grupo, al menos dos nodos se deben encontrar en funcionamiento para la elección de un nodo fuente. Si un grupo tiene cinco nodos, se requieren por lo menos tres nodos.
El tamaño de los grupos se establece con una cantidad impar de nodos en caso de que haya una partición de red que impida la comunicación entre los subgrupos del grupo de nodos. Si el tamaño del grupo es un número par, hay más posibilidades de que ambos subgrupos tengan una cantidad menor a la mayoría. Si el tamaño del grupo es un número impar, es más probable que uno de los subgrupos tenga la mayoría o que ninguno de los grupos la tenga.
En el siguiente diagrama, se compara un grupo de nodos en buen estado con uno degradado.
En el diagrama, se muestran dos grupos de nodos: uno funcional y uno degradado. El grupo de nodos que es completamente funcional y se encuentra en buen estado tiene tres miembros. En este estado, los nodos fuente y de réplica de la base de datos proporcionan su objetivo esperado. El quórum necesario para este grupo de nodos es de dos nodos.
En el grupo de nodos degradado, se muestra el estado cuando ya no se envían las señales de monitoreo de funcionamiento del nodo fuente debido a un error en la infraestructura. Puede que este estado sea el resultado de un error en la instancia del nodo de la base de datos fuente o que el nodo fuente aún se encuentre en ejecución. Como alternativa, puede que una partición de red impida la comunicación entre el nodo fuente y los demás nodos del grupo.
Independientemente de la causa, el resultado es que la réplica y el testigo determinan que el nodo fuente ya no se encuentra en buen estado. En este punto, mediante la mayoría de grupo, se realiza la elección de un nodo fuente, se determina que el nodo en espera activa se debe convertir en el nodo fuente y se inicia una conmutación por error.
En el siguiente diagrama, se muestra el flujo de transacciones, replicaciones y señales de monitoreo de funcionamiento de la base de datos en la arquitectura del nodo testigo.
En el diagrama anterior, esta arquitectura de HA se basa en que el nodo de réplica en espera activa comience a procesar las escrituras de producción con rapidez durante una conmutación por error. Los nodos de la base de datos en el grupo realizan los procedimientos de la conmutación por error, por ejemplo, la promoción del nodo fuente.
Para implementar esta arquitectura, considera los siguientes dos proyectos:
- La replicación de grupos de MySQL es un complemento de código abierto para MySQL que facilita la creación de topologías de HA.
- El clúster de Galera y el clúster de Percona XtraDB son otras opciones de código abierto que pueden proporcionar alta disponibilidad.
Ventajas
La arquitectura en espera activa tiene pocas partes móviles, es fácil de implementar y proporciona varias ventajas:
- Con solo un nodo testigo adicional de bajo costo, se proporciona una conmutación por error automatizada por completo.
- Esta arquitectura puede resolver un error a largo plazo en la infraestructura con la misma facilidad con la que puede resolver un error transitorio (por ejemplo, debido a un reinicio del sistema).
- Con cierta latencia de replicación asociada, se proporciona HA multirregión.
Consideraciones
La conmutación por error es automática. Sin embargo, aún debes realizar las siguientes tareas operativas:
- Administrar la replicación entre los nodos fuente y de réplica
- Administrar los nodos testigo
- Implementar y administrar el enrutamiento de la conexión mediante un balanceador de cargas
- No puedes dirigir lecturas al nodo de réplica sin realizar cambios en la lógica de la aplicación, lo que está fuera del alcance de este documento
HA con Orchestrator y ProxySQL
Si combinas los componentes de código abierto, Orchestrator y ProxySQL, obtienes una arquitectura que puede detectar las interrupciones y realizar una conmutación por error automática del tráfico desde un nodo fuente afectado hacia una réplica en buen estado que se haya promocionado de forma reciente.
Además, puedes enrutar consultas con transparencia a los nodos adecuados de lectura, o de lectura y escritura, para mejorar el rendimiento del nivel de datos de estado estable.
Orchestrator es una solución de código abierto para la conmutación por error y la administración de topologías de replicación de MySQL. El software te permite detectar topologías de replicación complejas y realizar consultas y refactorizaciones en estas. Además, ofrece una detección de fallas, una recuperación inteligente y una promoción confiables.
ProxySQL es un proxy de la base de datos para MySQL que está adaptado al protocolo, es de código abierto y de alto rendimiento, y cuenta con alta disponibilidad. ProxySQL escala millones de conexiones en cientos de miles de servidores de backend.
En el siguiente diagrama, se muestra la arquitectura combinada de Orchestrator y ProxySQL.
En esta arquitectura, como se ilustra en el diagrama anterior, un balanceador de cargas interno enruta el tráfico vinculado con la base de datos a instancias redundantes de ProxySQL. Estas instancias enrutan el tráfico a una instancia de la base de datos con capacidad de escritura o lectura en función de la configuración de ProxySQL.
Orchestrator proporciona los siguientes pasos para la recuperación y la detección de fallas:
- Orchestrator determina que el nodo de la base de datos fuente no está disponible.
- Se consultan todos los nodos de réplica para proporcionar una segunda opinión acerca del estado del nodo fuente.
- Si las réplicas proporcionan una evaluación coherente en la que se concluye que el nodo fuente no está disponible, la conmutación por error continúa.
- Tal como lo define la topología, el nodo promocionado se convierte en el nuevo nodo fuente durante la conmutación por error.
- Cuando se completa la conmutación por error, Orchestrator ayuda a garantizar que se aprovisione la cantidad correcta de nodos de replicación nuevos, de acuerdo con la topología.
Mediante la replicación en curso entre la base de datos principal en la zona A y las réplicas de la base de datos en las zonas alternativas, se mantienen actualizadas las réplicas con cualquier escritura enrutada a la fuente. Orchestrator verifica el estado de las bases de datos fuente y de réplica mediante el envío continuo de señales de monitoreo de funcionamiento. El estado de la aplicación de Orchestrator se conserva en una base de datos diferente de Cloud SQL. Si es necesario realizar cambios en la topología, Orchestrator también puede enviar comandos a las bases de datos.
ProxySQL enruta el tráfico de forma adecuada a los nuevos nodos fuente y de réplica cuando se completa la conmutación por error. Los servicios siguen abordando el nivel de datos mediante el uso de la dirección IP del balanceador de cargas. La dirección IP virtual cambia del nodo fuente anterior al nodo fuente nuevo sin problemas.
Ventajas
La automatización y los componentes de la arquitectura proporcionan las siguientes ventajas:
- El software que se usa en esta arquitectura proporciona varias funciones de observabilidad, entre las que se incluyen los grafos de la topología de replicación y la visibilidad del tráfico de consultas.
- ProxySQL y Orchestrator se coordinan para proporcionar una promoción y una conmutación por error automáticas de las réplicas.
- La política de promoción de réplicas se puede configurar por completo. A diferencia de lo que sucede en otros parámetros de configuración de HA, puedes optar por promocionar un nodo de réplica específico para que sea la fuente en el caso de una conmutación por error.
- Después de una conmutación por error, las réplicas nuevas se aprovisionan de forma declarativa en función de la topología.
- ProxySQL proporciona un beneficio complementario de balanceo de cargas, ya que enruta con transparencia las solicitudes de lectura y escritura a los nodos fuente y de réplica adecuados en función de las políticas configuradas.
Consideraciones
Esta arquitectura aumenta la responsabilidad operativa y genera costos adicionales de hosting debido a los siguientes factores:
- Orchestrator y ProxySQL se deben implementar y mantener.
- Orchestrator necesita una base de datos independiente para mantener el estado.
- Orchestrator y ProxySQL se deben configurar para la alta disponibilidad, lo que implica una complejidad adicional de configuración y de implementación.
Además, Orchestrator no es compatible con las replicaciones de varias fuentes ni con ninguno de los tipos de replicación paralela, y no se puede combinar con software de agrupamiento en clústeres, como Galera o Percona XtraDB. Para obtener más información sobre las limitaciones actuales, consulta Preguntas frecuentes sobre Orchestrator.
¿Qué sigue?
- Lee sobre la configuración de alta disponibilidad en Cloud SQL.
- Obtén más información sobre las opciones de alta disponibilidad en las que se usan discos persistentes regionales.
- Consulta la documentación sobre la replicación de grupos de MySQL.
- Obtén más información sobre el clúster de Galera o el clúster de Percona XtraDB relacionado.
- Consulta la documentación de Orchestrator.
- Obtén más información sobre ProxySQL.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.