En Citymobil utilizamos una base de datos MySQL como nuestro principal almacenamiento de datos persistente. Contamos con varios clusters de bases de datos para diversos servicios y propósitos.

La disponibilidad constante del maestro es un indicador crítico del rendimiento de todo el sistema y sus partes individuales. La recuperación automática del clúster en caso de una falla maestra reduce en gran medida el tiempo de respuesta a incidentes y el tiempo de inactividad del sistema. En este artículo, analizaré un diseño de alta disponibilidad (HA) para un clúster MySQL basado en Orquestador MySQL y direcciones IP virtuales (VIP).

Solución HA basada en VIP

Primero te contaré brevemente cuál es nuestro sistema de almacenamiento de datos.

Usamos un esquema de replicación clásico con un maestro accesible para escritura y múltiples réplicas de solo lectura. Un clúster puede contener un maestro intermedio: un nodo que es a la vez una réplica y un maestro para otros. Los clientes acceden a las réplicas a través de HAProxy, lo que permite una distribución uniforme de la carga y un fácil escalado. El uso de HAProxy se debe a razones históricas y actualmente estamos en el proceso de migración a ProxySQL.

La replicación se realiza en modo semisincrónico basado en GTID. Esto significa que al menos una réplica debe registrar una transacción antes de que se considere exitosa. Este modo de replicación proporciona un equilibrio óptimo entre rendimiento y seguridad de los datos en caso de falla del nodo maestro. Básicamente, todos los cambios se transfieren del maestro a las réplicas usando Row Based Replication (RBR), pero algunos nodos pueden tener mixed binlog format.

El orquestador actualiza periódicamente el estado de la topología del clúster, analiza la información recibida y, si surgen problemas, puede iniciar un procedimiento de recuperación automática. El desarrollador es responsable del procedimiento en sí, ya que puede implementarse de diferentes formas: basado en VIP, DNS, utilizando servicios de descubrimiento de servicios o mecanismos autoescritos.

Una forma sencilla de restaurar un maestro si falla es utilizar direcciones VIP flotantes.

Lo que necesita saber sobre esta solución antes de seguir adelante:

• Una VIP es una dirección IP que no está asociada con una interfaz de red física específica. Si un nodo falla o durante el mantenimiento programado, podemos cambiar el VIP a otro recurso con un tiempo de inactividad mínimo.
• Liberar y emitir una dirección IP virtual es una operación rápida y económica.
• Para trabajar con VIP, necesita acceso al servidor a través de SSH o el uso de utilidades especiales, por ejemplo, keepalived.

Veamos posibles problemas con nuestro asistente e imaginemos cómo debería funcionar el mecanismo de recuperación automática.

La conectividad de red con el maestro ha desaparecido o ha surgido un problema a nivel de hardware y el servidor no está disponible

1. El orquestador actualiza la topología del clúster y cada réplica informa que el maestro no está disponible. El orquestador inicia el proceso de selección de una réplica adecuada para la función del nuevo maestro y comienza la recuperación.
2. Estamos intentando eliminar el VIP del viejo maestro, sin éxito.
3. La réplica cambia al rol de maestro. La topología se está reconstruyendo.
4. Agregando una nueva interfaz de red con VIP. Como no fue posible eliminar el VIP, comenzamos a enviar periódicamente una solicitud en segundo plano. ARP gratuito. Este tipo de solicitud/respuesta le permite actualizar la tabla de asignación de direcciones IP y MAC en los conmutadores conectados, notificándole así que nuestro VIP se ha movido. Esto minimiza la probabilidad split brain al devolver al viejo maestro.
5. Todas las conexiones nuevas se redirigen inmediatamente al nuevo maestro. Las conexiones antiguas fallan y se realizan repetidas llamadas a la base de datos en el nivel de la aplicación.

El servidor está funcionando en modo normal, se produjo una falla a nivel de DBMS

El algoritmo es similar al caso anterior: actualizando la topología e iniciando el proceso de recuperación. Dado que el servidor está disponible, liberamos con éxito el VIP en el maestro anterior, lo transferimos al nuevo y enviamos varias solicitudes ARP. La posible devolución del antiguo maestro no debería afectar el clúster reconstruido ni el funcionamiento de la aplicación.

Otros problemas

Fallo de réplicas o masters intermedios no conduce a acciones automáticas y requiere intervención manual.

Una interfaz de red virtual siempre se agrega temporalmente, es decir, después de reiniciar el servidor, el VIP no se asigna automáticamente. Cada instancia de base de datos se inicia en modo de solo lectura de forma predeterminada, el orquestador cambia automáticamente el nuevo maestro a escritura e intenta instalar read only sobre el viejo maestro. Estas acciones tienen como objetivo reducir la probabilidad split brain.

Pueden surgir problemas durante el proceso de recuperación, que también deben notificarse a través de la interfaz de usuario del orquestador, además de las herramientas de monitoreo estándar. Hemos ampliado la API REST agregando esta característica (PR actualmente bajo revisión).

El diagrama general de la solución HA se presenta a continuación.

Elegir un nuevo maestro

El orquestador es lo suficientemente inteligente e intenta elegir la réplica más adecuada como nuevo maestro de acuerdo con los siguientes criterios:

• la réplica va por detrás del maestro;
• Versión MySQL de maestro y réplica;
• tipo de replicación (RBR, SBR o mixta);
• ubicación en el mismo o en diferentes centros de datos;
• presencia errant GTID — transacciones que se ejecutaron en la réplica y no en el maestro;
• También se tienen en cuenta las reglas de selección personalizadas.

No todas las señales son candidatas ideales para un maestro. Por ejemplo, se puede utilizar una réplica para hacer una copia de seguridad de los datos o el servidor tiene una configuración de hardware más débil. orquestador apoyo Reglas manuales con las que puede personalizar sus preferencias de selección de candidatos, desde los más preferidos hasta los ignorados.

Tiempo de respuesta y recuperación.

En caso de un incidente, es importante minimizar el tiempo de inactividad del sistema, así que consideremos los parámetros de MySQL que afectan la creación y actualización de la topología del clúster por parte del orquestador:

• slave_net_timeout — el número de segundos durante los cuales la réplica espera que lleguen nuevos datos o una señal de latido del maestro antes de que se reconozca que la conexión se perdió y se vuelva a conectar. Cuanto menor sea el valor, más rápido podrá la réplica determinar que la comunicación con el maestro está interrumpida. Establecemos este valor en 5 segundos.
• MASTER_CONNECT_RETRY — número de segundos entre intentos de reconexión. En caso de problemas de red, un valor bajo para este parámetro permitirá una reconexión rápida y evitará que se inicie el proceso de recuperación del clúster. El valor recomendado es 1 segundo.
• MASTER_RETRY_COUNT — número máximo de intentos de reconexión.
• MASTER_HEARTBEAT_PERIOD — intervalo en segundos después del cual el maestro envía una señal de latido. El valor predeterminado es la mitad del valor. slave_net_timeout.

Opciones de orquestador:

• DelayMasterPromotionIfSQLThreadNotUpToDate - si es igual true, la función maestra no se aplicará en la réplica candidata hasta que el subproceso SQL de la réplica haya completado todas las transacciones no aplicadas del registro de retransmisión. Usamos esta opción para evitar perder transacciones cuando todas las réplicas candidatas se quedan atrás.
• InstancePollSeconds — frecuencia de construcción y actualización de la topología.
• RecoveryPollSeconds — frecuencia del análisis de topología. Si se detecta un problema, se inicia la recuperación de la topología. Este constante, igual a 1 segundo.

El orquestador sondea cada nodo del clúster una vez cada InstancePollSeconds segundos Cuando se detecta un problema, se fuerza el estado del clúster actualizadoy luego se toma la decisión final de realizar la recuperación. Al experimentar con diferentes parámetros de base de datos y orquestador, pudimos reducir el tiempo de respuesta y recuperación a 30 segundos.

Banco de pruebas

Comenzamos a probar el esquema HA con el desarrollo de un local Banco de pruebas y una mayor implementación en entornos de prueba y producción. El stand local está completamente automatizado basado en Docker y le permite experimentar con la configuración del orquestador y la red, escalar el clúster de 2 a 3 servidores a varias docenas y realizar ejercicios en un entorno seguro.

Durante los ejercicios, elegimos uno de los métodos de emulación de problemas: disparar instantáneamente al maestro usando kill -9, finalice suavemente el proceso y detenga el servidor (docker-compose stop), simular problemas de red usando iptables -j REJECT o iptables -j DROP. Esperamos los siguientes resultados:

• el orquestador detectará problemas con el maestro y actualizará la topología en no más de 10 segundos;
• el procedimiento de recuperación se iniciará automáticamente: la configuración de la red cambiará, el rol del maestro pasará a la réplica, se reconstruirá la topología;
• se podrá escribir en el nuevo maestro y las réplicas activas no se perderán durante el proceso de reconstrucción;
• los datos comenzarán a escribirse en el nuevo maestro y a replicarse;
• El tiempo total de recuperación no será superior a 30 segundos.

Como sabe, el sistema puede comportarse de manera diferente en entornos de prueba y producción debido a diferentes configuraciones de hardware y red, diferencias en carga sintética y real, etc. Por eso, periódicamente realizamos ejercicios en condiciones reales, comprobando cómo se comporta el sistema cuando se pierde la conectividad de la red o se degradan sus partes individuales. En el futuro, queremos construir una infraestructura completamente idéntica para ambos entornos y automatizar sus pruebas.

Hallazgos

La salud del nodo principal del sistema de almacenamiento es una de las principales tareas del SRE y del equipo de operaciones. La implementación del orquestador y solución HA basada en VIP nos permitió lograr los siguientes resultados:

• detección confiable de problemas con la topología del clúster de bases de datos;
• Respuesta automática y rápida a incidencias relacionadas con el master, reduciendo el tiempo de inactividad del sistema.

Sin embargo, la solución tiene sus limitaciones y desventajas:

• escalar el esquema HA a varios centros de datos requerirá una única red L2 entre ellos;
• Antes de asignar VIP al nuevo maestro, debemos liberarlo en el antiguo. El proceso es secuencial, lo que aumenta el tiempo de recuperación;
• La liberación del VIP requiere acceso SSH al servidor o cualquier otro método para llamar a procedimientos remotos. Dado que el servidor o la base de datos están experimentando problemas que causaron el proceso de recuperación, no podemos estar seguros de que la eliminación de VIP se complete exitosamente. Y esto puede provocar la aparición de dos servidores con la misma dirección IP virtual y un problema. split brain.

Para evitar split brain, puedes usar el método STONITH (“Dispara al otro nodo en la cabeza”), que aísla o desactiva completamente el nodo problemático. Hay otras formas de implementar la alta disponibilidad del clúster: una combinación de VIP y DNS, descubrimiento de servicios y servicios de proxy, replicación sincrónica y otros métodos que tienen sus propias desventajas y ventajas.

Hablé sobre nuestro enfoque para crear un clúster de conmutación por error de MySQL. Es fácil de implementar y proporciona un nivel aceptable de confiabilidad en las condiciones actuales. A medida que se desarrolle todo el sistema en general y la infraestructura en particular, este enfoque sin duda evolucionará.

Fuente: habr.com