En este documento se describen varias arquitecturas que proporcionan alta disponibilidad para las implementaciones de MySQL en Google Cloud. La alta disponibilidad es la medida de la resiliencia del sistema en respuesta a un fallo de la infraestructura subyacente. En este documento, la alta disponibilidad hace referencia a la disponibilidad de los clústeres de MySQL en una sola región de la nube.
Este documento está dirigido a administradores de bases de datos, arquitectos de la nube e ingenieros de DevOps que quieran saber cómo aumentar la fiabilidad de la capa de datos de MySQL mejorando el tiempo de actividad general del sistema. Este documento está dirigido a los usuarios que ejecutan MySQL en Compute Engine. Si usas Cloud SQL para MySQL, este documento no es para ti.
En un sistema o una aplicación que requiera un estado persistente para gestionar solicitudes o transacciones, la capa de persistencia de datos debe estar disponible para gestionar correctamente las solicitudes de consultas o mutaciones de datos. Si la aplicación debe interactuar con el nivel de datos para atender las solicitudes, cualquier tiempo de inactividad en el nivel de datos impide que la aplicación realice las tareas necesarias.
En función de los objetivos de nivel de servicio del sistema, es posible que necesites una topología de arquitectura que proporcione un mayor nivel de disponibilidad. Hay más de una forma de conseguir la alta disponibilidad, pero, en general, se aprovisiona una infraestructura redundante a la que se puede acceder rápidamente desde la aplicación.
En este documento se tratan los siguientes temas:
- Definir términos para ayudarte a entender los conceptos de las bases de datos de alta disponibilidad.
- Ayudarte a comprender varias opciones de topologías de MySQL de alta disponibilidad.
- Proporciona información contextual para ayudarte a entender qué debes tener en cuenta en cada opción.
Terminología
Hay varios términos y conceptos que son estándar en el sector y que es útil conocer para fines que van más allá del alcance de este documento.
Replicación. Proceso por el que las transacciones de escritura (INSERT, UPDATE o DELETE) se registran y se aplican de forma fiable y secuencial a todos los nodos de la base de datos de la topología.
Réplica síncrona. Método de replicación de datos que asegura la coherencia de los datos en tiempo real escribiendo simultáneamente en las bases de datos primarias y de réplica.
Réplica semisíncrona. Método de replicación de datos que garantiza un grado limitado de coherencia de los datos escribiendo simultáneamente en la base de datos principal y en al menos otra base de datos de réplica.
Replicación asíncrona. Método de replicación de datos que permite que haya un retraso entre las actualizaciones de la réplica y las de la principal, lo que prioriza el rendimiento sobre la coherencia inmediata.
Nodo de origen. Todas las escrituras de la base de datos deben dirigirse a un nodo de origen. El nodo de origen proporciona una lectura con el estado más actualizado de los datos persistentes.
Nodo de réplica. Una copia online del nodo de la base de datos de origen. Los cambios se replican casi de forma síncrona en los nodos de réplica desde el nodo de origen. Puedes leer de los nodos de réplica sabiendo que los datos pueden retrasarse ligeramente debido a la latencia de replicación.
Latencia de replicación. Medida de tiempo que expresa la diferencia entre el momento en que se aplica una transacción a la réplica y el momento en que se aplica al nodo de origen.
Tiempo de actividad. El porcentaje de tiempo que un recurso está operativo y puede enviar una respuesta a una solicitud.
Detección de fallos. Proceso para identificar que se ha producido un fallo en la infraestructura.
Conmutación por error. Proceso para promover la infraestructura de reserva (en este caso, el nodo de réplica) para que se convierta en la infraestructura principal (el nodo de origen).
Objetivo de tiempo de recuperación (RTO). La duración, en tiempo real transcurrido, que es aceptable desde el punto de vista empresarial para que el nivel de datos esté sin conexión hasta que se complete el proceso de conmutación por error.
Objetivo de punto de recuperación (RPO). Duración, en tiempo real transcurrido, que se considera aceptable desde el punto de vista empresarial para que se pierdan datos hasta que se complete el proceso de conmutación por error.
Fallback. Proceso para restaurar el nodo de origen anterior después de que se haya producido una conmutación por error.
Autorreparación. Capacidad de un sistema para resolver problemas sin que un operador humano tenga que realizar acciones externas.
Partición de red. Situación en la que dos nodos de una topología, por ejemplo, los nodos de origen y de réplica, no pueden comunicarse entre sí a través de la red.
Cerebro dividido. Condición que se produce cuando dos nodos creen simultáneamente que son el nodo de origen.
Grupo de nodos. Un conjunto de tareas de recursos de computación que proporcionan un servicio. En este documento, ese servicio es el nivel de persistencia de datos.
Nodo de testigo o de quórum. Un recurso de computación independiente que ayuda a un grupo de nodos a determinar qué hacer cuando se produce una condición de cerebro dividido.
Elección de la fuente o del líder. Proceso por el que un grupo de nodos con reconocimiento entre iguales, incluidos los nodos de testigo, determina qué nodo debe ser el nodo de origen.
Grupo de nodos. Un conjunto de tareas de recursos de computación que proporcionan un servicio. En este documento, ese servicio es el nivel de persistencia de datos.
Hot standby. Nodo que representa una copia casi exacta de otro nodo de origen y que puede convertirse en el nuevo nodo de origen con un tiempo de inactividad mínimo.
Cuándo plantearse una arquitectura de alta disponibilidad
Las arquitecturas de alta disponibilidad ofrecen una mayor protección frente al tiempo de inactividad de la capa de datos. Es fundamental que conozcas tu tolerancia a los tiempos de inactividad y las ventajas e inconvenientes de las distintas arquitecturas para elegir la opción que mejor se adapte a tu caso práctico.
Usa una topología de alta disponibilidad cuando quieras aumentar el tiempo de actividad de la capa de datos para cumplir los requisitos de fiabilidad de tus cargas de trabajo y servicios. En los entornos en los que se tolera un tiempo de inactividad, una topología de alta disponibilidad introduce costes y complejidad innecesarios. Por ejemplo, los entornos de desarrollo o de prueba no suelen necesitar una alta disponibilidad de nivel de base de datos.
Ten en cuenta tus requisitos de alta disponibilidad
El coste es un factor importante, ya que los costes de la infraestructura de computación y del almacenamiento se duplicarán como mínimo para proporcionar alta disponibilidad. Es importante que evalúes detenidamente este coste en comparación con el posible impacto económico de los periodos de inactividad. Cuando evalúes las posibles opciones de alta disponibilidad 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 coste para tu empresa en caso de que se produzca un tiempo de inactividad en el nivel de persistencia de datos?
- ¿Hasta qué punto debe automatizarse el proceso?
- ¿Qué nivel de disponibilidad quieres conseguir: 99,5%, 99,9 % o 99,99%?
- ¿Con qué rapidez necesitas conmutar por error? ¿Cuáles son tus objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO)?
Los siguientes factores influyen en el tiempo de recuperación y deben tenerse en cuenta al establecer el RTO y el RPO:
- Detección de la interrupción
- Disponibilidad de la instancia de máquina virtual (VM) secundaria
- Tipo de replicación y frecuencia de las copias de seguridad
- Conmutación por error de almacenamiento
- Tiempo de recuperación de la base de datos
- Tiempo de recuperación de la aplicación
Arquitecturas de alta disponibilidad de MySQL
En el nivel más básico, la alta disponibilidad en la capa de datos consta de lo siguiente:
- Un mecanismo para identificar que se ha producido un fallo en el nodo de origen.
- Proceso para realizar una conmutación por error en la que el nodo de réplica se convierte en un nodo de origen.
- Un proceso para cambiar el enrutamiento de las consultas de forma que las solicitudes de la aplicación lleguen al nuevo nodo de origen.
- Opcionalmente, un método para volver a la topología original mediante nodos de origen y réplica.
En este documento se analizan las tres arquitecturas de alta disponibilidad siguientes:
Además de los fallos de infraestructura, cada una de estas arquitecturas puede ayudar a minimizar el tiempo de inactividad en el improbable caso de que se produzca una interrupción zonal. Estas arquitecturas se usan con cambios en el sistema de nombres de dominio (DNS) para proporcionar alta disponibilidad multirregional y protegerse frente a interrupciones del servicio regionales, pero en este documento se tratan las interrupciones zonales.
Alta disponibilidad con discos persistentes regionales
La alta disponibilidad en la capa de datos siempre se basa en algún tipo de replicación de datos. La replicación más sencilla es la que no tienes que gestionar.
Con la opción de almacenamiento disco persistente regional de Compute Engine, puedes aprovisionar un dispositivo de almacenamiento en bloques que proporcione replicación de datos síncrona entre dos zonas de una región. Los discos persistentes regionales proporcionan una base sólida para implementar servicios de alta disponibilidad en Compute Engine.
En el siguiente diagrama se muestra la arquitectura de alta disponibilidad con discos persistentes regionales.
Si la instancia de VM del nodo de origen deja de estar disponible debido a un fallo de la infraestructura o a una interrupción zonal, puedes forzar que el disco persistente regional se conecte a una instancia de VM de tu zona de copia de seguridad en la misma región.
Para realizar esta tarea, debes hacer una de las siguientes acciones:
- Inicia otra instancia de VM en la zona de copia de seguridad donde se pueda acceder al disco persistente regional compartido.
- Mantén una instancia de VM en espera activa en la zona de copia de seguridad. Una instancia de VM de espera activa es una instancia de VM en ejecución idéntica a la instancia que estás usando. Una vez que hayas conectado el disco persistente regional, podrás iniciar el motor de la base de datos.
Si la interrupción del servicio de datos se identifica rápidamente, la operación de asociación forzada suele completarse en menos de un minuto, lo que significa que se puede alcanzar un tiempo de recuperación (RTO) medido en minutos, con un objetivo de punto de recuperación (RPO) de cero.
Si tu empresa puede tolerar el tiempo de inactividad adicional necesario para detectar y comunicar una interrupción, y para realizar la conmutación por error manualmente, no es necesario automatizar el proceso.
Si tu tolerancia de RTO es menor, puedes automatizar el proceso de detección y conmutación por error. Si automatizas esta arquitectura, el sistema se complica aún más, ya que hay varios casos límite en el proceso de conmutación por error y de respaldo que debes tener en cuenta. Para obtener más información sobre una implementación totalmente automatizada de esta arquitectura, consulta la configuración de alta disponibilidad de Cloud SQL.
Ventajas
Usar discos persistentes regionales para conseguir la alta disponibilidad ofrece varias ventajas gracias a las siguientes funciones:
Esta arquitectura ofrece protección simultánea frente a varios modos de fallo: fallo de la infraestructura de la zona del servidor de origen, degradación del almacenamiento en bloque de una sola zona o interrupción total de la zona.
No es necesario replicar la capa de aplicación o de base de datos porque los discos persistentes regionales proporcionan una replicación de datos continua y síncrona a nivel de bloque, que gestiona por completo Google Cloud. Un Persistent Disk regional detecta automáticamente los errores y la lentitud, cambia el modo de réplica y pone al día los datos que se replican en una sola zona.
Si hay problemas de almacenamiento en una zona principal, un disco persistente regional realiza automáticamente lecturas desde la zona secundaria. Esta operación puede provocar un aumento de la latencia de lectura, pero tu aplicación puede seguir funcionando sin que tengas que hacer nada manualmente.
Cuestiones importantes
Las limitaciones de esta arquitectura están relacionadas con la naturaleza de una sola región de esta topología y con algunas de las siguientes restricciones inherentes de los discos persistentes regionales:
- El Persistent Disk regional solo se puede montar en una base de datos. Aunque la instancia de VM de la base de datos de espera esté en ejecución, no se puede usar para atender lecturas de la base de datos. Sin embargo, con la alta disponibilidad de Hyperdisk Balanced de Google Cloud en el modo multiescritura, varias instancias pueden leer y escribir en el mismo disco. Para obtener más información sobre Hyperdisk, consulta el artículo Acerca de Hyperdisk.
- La tecnología subyacente de esta arquitectura solo permite la replicación entre zonas de la misma región. Por lo tanto, la conmutación por error regional no es una opción cuando se usa únicamente esta arquitectura.
- El rendimiento de escritura de los discos persistentes regionales se reduce a la mitad en comparación con los discos persistentes zonales. Asegúrate de que los límites de rendimiento se ajustan a la tolerancia que necesitas.
- La latencia de escritura de los discos persistentes regionales es ligeramente superior a la de los discos persistentes de zona. Te recomendamos que pruebes tu carga de trabajo para verificar que el rendimiento de escritura es aceptable para tus requisitos.
- Durante un evento de fallo y el cambio resultante, debes forzar que el disco persistente regional se conecte a la VM de la zona de espera. La operación de conexión forzada suele ejecutarse en menos de un minuto, por lo que debes tener en cuenta este tiempo al evaluar tu RTO.
- La estimación del RTO debe tener en cuenta el tiempo necesario para forzar la conexión del disco persistente regional y la detección del disco conectado en caliente por parte del sistema de archivos de la VM.
Alta disponibilidad con nodo de espera activo y nodo testigo
Si quieres una conmutación por error automática, necesitas otra arquitectura. Una opción es implementar un grupo de al menos dos nodos de base de datos, configurar la replicación asíncrona de la base de datos e iniciar nodos de testigo para ayudar a garantizar que se pueda alcanzar un quórum durante una elección de nodo de origen.
El nodo de la base de datos de origen procesa las transacciones de escritura y responde a las consultas de lectura. El proceso de replicación de la base de datos transmite los cambios al nodo de réplica de espera activa online.
Como el nodo testigo puede ser una máquina virtual pequeña, proporciona un mecanismo de bajo coste para asegurarse de que la mayoría de un grupo esté disponible para la elección de un nodo de origen.
Los nodos de grupo evalúan continuamente el estado de los demás nodos de grupo. Las señales que consumen estas comprobaciones de estado cada pocos segundos se denominan latidos porque se usan para evaluar el estado de los demás nodos del grupo. Es importante evaluar a tiempo el estado de los nodos de la base de datos, ya que es necesario identificar rápidamente los nodos de la base de datos de origen que no estén en buen estado para poder iniciar una conmutación por error de la réplica activa.
El quórum del grupo de nodos se determina por el número de elementos de voto que deben formar parte de la pertenencia activa al clúster para que este se inicie correctamente o siga funcionando. Para que un grupo de nodos alcance el quórum en una elección de nodo de base de datos de origen, debe participar la mayoría de los nodos del grupo. Para evitar una situación de cerebro dividido, el requisito de mayoría asegura que, en caso de partición de la red, dos grupos de votación no puedan tener simultáneamente suficientes nodos para votar.
Una mayoría de un grupo consta de (n+1)/2 nodos, donde n es el número total de nodos del grupo. Por ejemplo, si hay tres nodos en un grupo, al menos dos nodos deben estar operativos para que se elija un nodo de origen. Si hay cinco nodos en un grupo, se necesitan al menos tres nodos.
Los grupos tienen un número impar de nodos por si se produce una partición de red que impida la comunicación entre subgrupos del grupo de nodos. Si el grupo es par, hay más probabilidades de que ambos subgrupos tengan menos de la mayoría. Si el tamaño del grupo es impar, es más probable que uno de los subgrupos tenga la mayoría o que ninguno de los grupos tenga la mayoría.
En el siguiente diagrama se compara un grupo de nodos correcto con un grupo de nodos degradado.
En el diagrama se muestran dos grupos de nodos: un grupo de nodos funcional y un grupo de nodos degradado. El grupo de nodos completamente funcional y correcto tiene tres miembros. En este estado, los nodos de la base de datos de origen y de réplica cumplen su función. El quórum necesario para este grupo de nodos es de dos nodos.
El grupo de nodos degradado muestra el estado en el que las señales de latido del nodo de origen ya no se envían debido a un fallo de la infraestructura. Este estado puede deberse a un fallo en la instancia del nodo de la base de datos de origen o a que el nodo de origen siga en ejecución. También puede ocurrir que una partición de red impida la comunicación entre el nodo de origen y los demás nodos del grupo.
Independientemente de la causa, tanto la réplica como el testigo determinan que el nodo de origen ya no está en buen estado. En este punto, la mayoría del grupo lleva a cabo una elección de nodo de origen, determina que el nodo de espera activo debe convertirse en el nodo de origen e inicia una conmutación por error.
En el siguiente diagrama se muestra el flujo de transacciones, replicación y latido de la base de datos en la arquitectura de nodos de testigo.
En el diagrama anterior, esta arquitectura de alta disponibilidad se basa en el nodo de réplica de espera activa para empezar a procesar rápidamente las escrituras de producción en caso de conmutación por error. Los mecanismos de la conmutación por error (por ejemplo, la promoción del nodo de origen) los llevan a cabo los nodos de la base de datos del grupo.
Para implementar esta arquitectura, ten en cuenta los dos proyectos siguientes:
- Replicación de grupos de MySQL es un complemento de código abierto para MySQL que facilita la creación de topologías de alta disponibilidad.
- Galera Cluster y Percona XtraDB Cluster son otras opciones de código abierto que pueden proporcionar alta disponibilidad.
Ventajas
La arquitectura de espera activa tiene pocas piezas móviles, es fácil de implementar y ofrece varias ventajas:
- Con solo un nodo de testigo adicional de bajo coste, se proporciona una conmutación por error totalmente automatizada.
- Esta arquitectura puede hacer frente de forma eficaz a los fallos de infraestructura a largo plazo y a los fallos transitorios (por ejemplo, debido a un reinicio del sistema).
- Se proporciona alta disponibilidad multirregional con una latencia de replicación asociada.
Cuestiones importantes
La conmutación por error es automática, pero siguen siendo necesarias las siguientes tareas operativas:
- Tú gestionas la replicación entre los nodos de origen y de réplica.
- Tú gestionas los nodos de testigo.
- Debes implementar y gestionar el enrutamiento de la conexión mediante un balanceador de carga.
- Si no modificas la lógica de tu aplicación, lo que queda fuera del ámbito de este documento, no podrás dirigir las lecturas al nodo de réplica.
Alta disponibilidad con Orchestrator y ProxySQL
Si combinas los componentes de código abierto Orchestrator y ProxySQL, tendrás una arquitectura que puede detectar interrupciones y conmutar automáticamente el tráfico de un nodo de origen afectado a una réplica correcta recién ascendida.
Además, puede enrutar las consultas de forma transparente a los nodos de lectura o de lectura y escritura adecuados para mejorar el rendimiento de la capa de datos en estado estable.
Orchestrator es un gestor de topologías de replicación de MySQL de código abierto y una solución de conmutación por error. El software te permite detectar, consultar y refactorizar topologías de replicación complejas, así como proporcionar detección de errores fiable, recuperación inteligente y promoción.
ProxySQL es un proxy de código abierto, de alto rendimiento y de alta disponibilidad para MySQL que reconoce el protocolo de la base de datos. ProxySQL se puede escalar a millones de conexiones en cientos de miles de servidores backend.
En el siguiente diagrama se muestra la arquitectura combinada de Orchestrator y ProxySQL.
En esta arquitectura, tal como se muestra en el diagrama anterior, un balanceador de carga interno enruta el tráfico enlazado a la base de datos a instancias de ProxySQL redundantes. Estas instancias enrutan el tráfico a una instancia de base de datos con capacidad de escritura o lectura en función de la configuración de ProxySQL.
Orchestrator proporciona los siguientes pasos de detección y recuperación de errores:
- Orchestrator determina que el nodo de la base de datos de origen no está disponible.
- Se consulta a todos los nodos de réplica para obtener una segunda opinión sobre el estado del nodo de origen.
- Si las réplicas proporcionan una evaluación coherente de que la fuente no está disponible, se lleva a cabo la conmutación por error.
- Según la topología, el nodo promocionado se convierte en el nuevo nodo de origen durante la conmutación por error.
- Cuando se completa la conmutación por error, Orchestrator ayuda a asegurarse de que se aprovisione el número correcto de nodos de réplica nuevos según la topología.
La replicación continua entre la base de datos de origen de la zona A y las réplicas de la base de datos de las zonas alternativas mantiene las réplicas actualizadas con las escrituras dirigidas al origen. Orchestrator comprueba el estado de las bases de datos de origen y de réplica enviando continuamente señales de latido. El estado de la aplicación Orchestrator se conserva en una base de datos de Cloud SQL independiente. Si es necesario hacer cambios en la topología, Orchestrator también puede enviar comandos a las bases de datos.
ProxySQL dirige el tráfico correctamente a los nuevos nodos de origen y réplica cuando se completa la conmutación por error. Los servicios siguen dirigiéndose al nivel de datos mediante la dirección IP del balanceador de carga. La dirección IP virtual se cambia sin problemas del nodo de origen anterior al nuevo.
Ventajas
Los componentes de la arquitectura y la automatización ofrecen las siguientes ventajas:
- El software utilizado en esta arquitectura proporciona varias funciones de observabilidad, como gráficos de topología de replicación y visibilidad del tráfico de consultas.
- ProxySQL y Orchestrator se coordinan para proporcionar réplicas automáticas y conmutación por error.
- La política de promoción de réplicas es totalmente configurable. A diferencia de otras configuraciones de alta disponibilidad, puedes elegir promover un nodo de réplica específico a origen en caso de conmutación por error.
- Después de una conmutación por error, las nuevas réplicas se aprovisionan de forma declarativa según la topología.
- ProxySQL ofrece una ventaja adicional de balanceo de carga, ya que enruta de forma transparente las solicitudes de lectura y escritura a los nodos de réplica y de origen adecuados en función de las políticas configuradas.
Cuestiones importantes
Esta arquitectura aumenta la responsabilidad operativa y conlleva costes de alojamiento adicionales debido a los siguientes factores:
- Tanto Orchestrator como ProxySQL deben implementarse y mantenerse.
- Orchestrator necesita una base de datos independiente para mantener el estado.
- Tanto Orchestrator como ProxySQL deben configurarse para la alta disponibilidad, por lo que la configuración y la implementación son más complejas.
Además, Orchestrator no admite réplicas de varias fuentes, no admite todos los tipos de réplica paralela y no se puede combinar con software de clustering, como Galera o Percona XtraDB. Para obtener más información sobre las limitaciones actuales, consulta las preguntas frecuentes sobre Orchestrator.
Siguientes pasos
- Consulta información sobre la configuración de alta disponibilidad de Cloud SQL.
- Consulta más información sobre las opciones de alta disponibilidad con discos persistentes regionales.
- Consulta la documentación sobre la replicación de grupos de MySQL.
- Consulta información sobre Galera Cluster o el clúster Percona XtraDB relacionado.
- Consulta la documentación de Orchestrator.
- Consulta más información sobre ProxySQL.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.