sql >> Base de Datos >  >> RDS >> Mysql

Estructura de alta disponibilidad de MySQL explicada – Parte I:Introducción

En esta serie de blogs de tres partes, explicaremos los detalles y la funcionalidad de un marco de trabajo de alta disponibilidad (HA) para el hospedaje de MySQL mediante la replicación semisíncrona de MySQL y la pila Corosync más Pacemaker. En la Parte I, lo guiaremos a través de los conceptos básicos de alta disponibilidad, los componentes de un marco HA y luego le presentaremos el marco HA para MySQL.

¿Qué es la alta disponibilidad?

La disponibilidad de un sistema informático es el porcentaje de tiempo que sus servicios están activos durante un período de tiempo. Generalmente se expresa como una serie de 9's. Por ejemplo, la siguiente tabla muestra la disponibilidad y el tiempo de inactividad correspondiente medido durante un año.

% de disponibilidad Tiempo de inactividad por año
90 % (“un 9 “) 36,53 días
99 % (“dos 9 “) 3,65 días
99,9% ("tres 9s “) 8,77 horas
99,99% ("cuatro 9s “) 52,60 minutos
99,999 % ("cinco 9 “) 5,26 minutos
99,9999 % ("seis 9 “) 31,56 segundos

El significado de alta disponibilidad varía según los requisitos de su aplicación y negocio. Por ejemplo, si no puede permitirse un tiempo de inactividad de más de unos pocos minutos por año en su servicio, decimos que el servicio debe tener un 99,999 % de alta disponibilidad.

Componentes de un Framework HA

La esencia de tener una alta disponibilidad es la capacidad de recuperarse instantáneamente de fallas que pueden ocurrir en cualquier parte de un sistema. Hay cuatro componentes muy esenciales en cualquier marco HA que deben trabajar juntos de manera automatizada para permitir esta capacidad de recuperación. Repasemos  estos componentes en detalle:

1. Redundancia en Infraestructura y Datos

Para que un servicio tenga una alta disponibilidad, debemos asegurarnos de que haya una redundancia en el alojamiento de la infraestructura, así como una redundancia actualizada copia de los datos que el servicio utiliza o proporciona. Esto actúa como un servicio en espera listo para tomar el control en caso de que el principal se vea afectado por fallas.

2. Mecanismo de detección y corrección de fallas

Es extremadamente importante detectar de inmediato cualquier falla en cualquier parte del sistema principal que pueda afectar su disponibilidad. Esto permitirá que el marco tome medidas correctivas en el mismo sistema principal o realice la conmutación por error de los servicios a un sistema en espera.

3. Mecanismo de conmutación por error

Este componente maneja la responsabilidad de la conmutación por error de los servicios a su infraestructura de reserva. Tenga en cuenta que, en caso de que haya varios sistemas redundantes disponibles, este componente del mecanismo de conmutación por error debe identificar el sistema más adecuado entre ellos y promocionarlo como el servicio principal.

4. Mecanismo de redirección de aplicaciones/usuarios

Una vez que los sistemas de reserva se han convertido en el principal, este componente garantiza que todas las conexiones de aplicaciones y usuarios comiencen a realizarse en el nuevo principal.

Explicación del marco de alta disponibilidad de MySQL - Parte IHaga clic para twittear

El marco HA para MySQL

Basándonos en el modelo anterior, usamos el siguiente marco HA para nuestro hospedaje MySQL en ScaleGrid:

  • Una configuración maestro-esclavo de 3 nodos que utiliza la replicación semisincrónica de MySQL para proporcionar infraestructura y redundancia de datos.
  • La pila Corosync plus Pacemaker para proporcionar detección de fallas, corrección y mecanismo de conmutación por error.
  • Un componente de mapeo de DNS o IP virtual para proporcionar la aplicación y el mecanismo de redirección de usuarios.

Consulte el siguiente diagrama para visualizar la pila de software de esta arquitectura:

Revisemos la funcionalidad de algunos de los componentes clave en este marco.

  1. Corosync

    Corosync proporciona un marco de comunicación para los nodos con un intercambio de mensajes fiable entre ellos. Forma un anillo de clúster de nodos y realiza un seguimiento de los nodos que se unen y abandonan el clúster a través de la membresía del clúster. Corosync trabaja en estrecha colaboración con Pacemaker para comunicarse sobre la disponibilidad del nodo para que Pacemaker pueda tomar las decisiones adecuadas.

  2. Marpasos

    También conocido como Administrador de recursos de clúster (CRM), Pacemaker garantiza la alta disponibilidad de MySQL que se ejecuta en el clúster y detecta y maneja las fallas a nivel de nodo mediante la interfaz con Corosync. También detecta y maneja las fallas de MySQL al interactuar con Resource Agent (RA). Pacemaker configura y administra el recurso MySQL a través de operaciones de inicio, detención, monitoreo, promoción y degradación.

  3. Agente de recursos

    El Resource Agent actúa como una interfaz entre MySQL y Pacemaker. Implementa operaciones de inicio, detención, promoción, degradación y supervisión que invoca Pacemaker. Hay un agente de recursos completamente funcional llamado Percona Replication Manager (PRM) para MySQL implementado por Percona. Esto ha sido mejorado por ScaleGrid y está disponible en nuestra página de GitHub.

  4. Componente de asignación de DNS

    El agente de recursos, al completar una conmutación por error exitosa, invoca este componente que actualiza los registros DNS del servidor MySQL maestro con la dirección IP del nuevo maestro. Tenga en cuenta que los clientes siempre usan un nombre DNS maestro para conectarse con el servidor MySQL, y al administrar la asignación de este nombre DNS a la dirección IP del maestro actual, podemos asegurarnos de que los clientes no tengan que cambiar sus cadenas de conexión o propiedades cuando hay una conmutación por error.

En la Parte II de esta serie de blogs, aprenderá sobre el componente crítico de redundancia de datos que se logra mediante la replicación semisincrónica de MySQL. También profundizaremos en los detalles y las configuraciones de replicación semisincrónica que usamos para lograr nuestro soporte de alta disponibilidad y, por último, revisaremos varios escenarios de falla en la Parte III y la forma en que el marco responde y se recupera de estas condiciones.