En CityMobile, utilizamos la base de datos MySQL como almacenamiento principal para datos persistentes. Tenemos varios grupos de bases de datos para diversos servicios y propósitos.

La disponibilidad constante del asistente es un indicador crítico de la salud de todo el sistema y sus partes individuales. La recuperación automática del clúster en caso de falla del asistente reduce en gran medida el tiempo de respuesta a incidentes y el tiempo de inactividad del sistema. En este artículo, veré un clúster HA de MySQL basado en MySQL Orchestrator y direcciones IP virtuales (VIP).

VIP HA Solution

Primero, hablaré brevemente sobre cómo es nuestro sistema de almacenamiento de datos.

Usamos el esquema de replicación clásico con un asistente de solo escritura y muchas réplicas de solo lectura. Un clúster puede contener un maestro intermedio, un nodo que es tanto una réplica como un maestro para otros. Los clientes acceden a las réplicas a través de HAProxy, que permite una distribución uniforme de la carga y una escalabilidad sencilla. El uso de HAProxy se debe a razones históricas, y ahora estamos en el proceso de migrar a ProxySQL.

La replicación es semisíncrona basada enGTID. Esto significa que al menos una réplica debe escribir la transacción en el registro antes de que se considere exitosa. Este modo de replicación proporciona un equilibrio óptimo entre rendimiento y seguridad de datos en caso de falla del nodo principal. Básicamente, todos los cambios se transfieren del maestro a las réplicas utilizando 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, en caso de problemas, puede iniciar el procedimiento de recuperación automática. El desarrollador es responsable del procedimiento en sí, ya que se puede implementar de varias maneras: basado en VIP, DNS, utilizando servicios de descubrimiento de servicios o mecanismos independientes.

Una de las formas más fáciles de restaurar un asistente en caso de falla es usar direcciones VIP flotantes.

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

VIP es una dirección IP que no está vinculada a una interfaz de red física específica. Cuando un nodo falla o durante el trabajo 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 barata y rápida.
Para trabajar con el VIP se requiere acceso al servidor a través de SSH, o el uso de herramientas especiales, por ejemplo keepalived.

Consideraremos posibles problemas con nuestro maestro e imaginaremos cómo debería funcionar el mecanismo de recuperación automática.

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

, . , , .
VIP — .
. .
VIP. VIP , gratuitous ARP. / IP- MAC-, VIP. split brain .
Todas las conexiones nuevas se redirigen inmediatamente al nuevo maestro. Las conexiones antiguas fallan, se realizan llamadas repetidas a la base de datos a nivel de aplicación.

El servidor está funcionando en modo normal; se produjo un error en el nivel DBMS

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

Otros problemas

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

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

Durante el proceso de recuperación, pueden surgir problemas, 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 función ( actualmente se está considerando PR ).

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

Elegir un nuevo mago

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

retraso de la réplica del maestro;
Asistente de MySQL y versión de réplica;
tipo de replicación (RBR, SBR o mixto);
ubicación en uno o diferentes centros de datos;
disponibilidad errant GTID: transacciones que se realizaron en la réplica y están ausentes en el maestro;
las reglas de selección personalizadas también se tienen en cuenta.

No todas las réplicas son candidatas ideales para el papel de maestro. Por ejemplo, se puede usar 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. El orquestador admite reglas manuales mediante las cuales puede ajustar sus preferencias para elegir un candidato de los más preferidos a los ignorados.

Tiempo de respuesta y recuperación

En el caso de un incidente, es importante minimizar el tiempo de inactividad del sistema, por lo tanto, consideramos los parámetros de MySQL que afectan la construcción y actualización de la topología del clúster por parte de la orquesta:

slave_net_timeout- el número de segundos durante los cuales la réplica espera nuevos datos o una señal de latido del maestro antes de que la conexión se reconozca como perdida y se realice la reconexión. Cuanto menor sea el valor, más rápido podrá la réplica determinar que la conexión con el maestro está interrumpida. Establecemos este valor en 5 segundos.
MASTER_CONNECT_RETRY- el número de segundos entre intentos de reconexión. En caso de problemas de red, un valor bajo de este parámetro le permitirá reconectarse rápidamente y evitar el inicio del proceso de recuperación del clúster. El valor recomendado es 1 segundo.
MASTER_RETRY_COUNT - El número máximo de intentos de reconexión.
MASTER_HEARTBEAT_PERIOD- el 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 del asistente no se aplicará en la réplica candidata hasta que la secuencia SQL de réplica complete todas las transacciones no aplicadas del Registro de retransmisión. Utilizamos esta opción para no perder transacciones cuando todas las réplicas candidatas están detrás.
InstancePollSeconds - la frecuencia de construcción y actualización de la topología.
RecoveryPollSeconds- frecuencia de análisis de topología. Si se detecta un problema, comienza la recuperación de la topología. Esta es una constante igual a 1 segundo.

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

Banco de pruebas

Comenzamos a probar el esquema HA desarrollando un banco de pruebas local e implementándolo en un entorno de prueba y combate. El stand local está completamente automatizado basado en Docker y le permite experimentar con la configuración de la orquesta y la red, escalar el clúster de 2-3 servidores a varias decenas y realizar ejercicios en un entorno seguro.

Durante los ejercicios, elegimos uno de los métodos para emular el problema: disparar instantáneamente al asistente kill -9, completar suavemente el proceso y detener el servidor ( docker-compose stop), simular problemas de red con iptables -j REJECTo iptables -j DROP. Esperamos estos resultados:

la orquesta detectará problemas con el maestro y actualizará la topología en no más de 10 segundos;
el procedimiento de recuperación comenzará automáticamente: la configuración de la red cambiará, el rol del asistente irá a la réplica, la topología será reconstruida;
el nuevo maestro estará disponible para grabación, las réplicas en vivo no se perderán en el proceso de reconstrucción;
los datos comenzarán a escribirse en el nuevo maestro y replicarse;
El tiempo total de recuperación no será más de 30 segundos.

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

recomendaciones

La operabilidad del nodo principal del sistema de almacenamiento es una de las tareas principales del equipo y la operación de SRE. La introducción de la orquesta y las soluciones HA basadas en VIP permitieron lograr los siguientes resultados:

detección confiable de problemas con la topología del clúster de base de datos;
Respuesta automática y rápida a incidentes relacionados con el maestro, lo que reduce 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 sola red L2 entre ellos;
Antes de asignar un VIP al nuevo maestro, necesitamos liberarlo del anterior. El proceso es secuencial, lo que aumenta el tiempo de recuperación;
VIP SSH- , . , , , VIP . IP- split brain.

Para evitarlo split brain, puede utilizar el método STONITH ("Disparar el otro nodo en la cabeza"), que aísla o desconecta completamente el nodo del problema. Existen otras formas de implementar la alta disponibilidad del clúster: una combinación de VIP y DNS, descubrimiento de servicios y servicios proxy, replicación sincrónica y otros métodos que tienen sus inconvenientes y ventajas.

Hablé sobre nuestro enfoque para crear un clúster de conmutación por error MySQL. Es fácil de implementar y proporciona un nivel aceptable de confiabilidad en el entorno actual. Con el desarrollo de todo el sistema en su conjunto y la infraestructura en particular, este enfoque, sin duda, evolucionará.

Orchestrator y VIP como solución HA para el clúster MySQL