En Citymobil usamos unha base de datos MySQL como o noso principal almacenamento de datos persistente. Temos varios clústeres de bases de datos para diversos servizos e fins.

A dispoñibilidade constante do mestre é un indicador crítico do rendemento de todo o sistema e das súas partes individuais. A recuperación automática do clúster en caso de falla principal reduce moito o tempo de resposta aos incidentes e o tempo de inactividade do sistema. Neste artigo, analizarei un deseño de alta dispoñibilidade (HA) para un clúster de MySQL baseado MySQL Orchestrator e enderezos IP virtuais (VIP).

Solución HA baseada en VIP

En primeiro lugar, vouche dicir brevemente cal é o noso sistema de almacenamento de datos.

Usamos un esquema de replicación clásico cun mestre accesible para escribir e varias réplicas de só lectura. Un clúster pode conter un mestre intermedio, un nodo que é tanto unha réplica como un mestre para outros. Os clientes acceden ás réplicas a través de HAProxy, o que permite unha distribución uniforme da carga e un fácil escalado. O uso de HAProxy débese a razóns históricas e actualmente estamos en proceso de migración a ProxySQL.

A replicación realízase en modo semisíncrono baseado en GTID. Isto significa que polo menos unha réplica debe rexistrar unha transacción antes de que se considere exitosa. Este modo de replicación proporciona un equilibrio óptimo entre o rendemento e a seguridade dos datos en caso de falla dun nodo mestre. Basicamente, todos os cambios transfírense do mestre ás réplicas usando Row Based Replication (RBR), pero algúns nodos poden ter mixed binlog format.

O orquestrator actualiza periodicamente o estado da topoloxía do clúster, analiza a información recibida e, se aparecen problemas, pode iniciar un procedemento de recuperación automática. O desenvolvedor é o responsable do propio procedemento, xa que se pode implementar de diferentes xeitos: baseado en VIP, DNS, utilizando servizos de descubrimento de servizos ou mecanismos autoescritos.

Unha forma sinxela de restaurar un mestre se falla é usar enderezos VIP flotantes.

O que debes saber sobre esta solución antes de seguir adiante:

Un VIP é un enderezo IP que non está asociado a unha interface de rede física específica. Se un nodo falla ou durante o mantemento programado, podemos cambiar o VIP a outro recurso cun tempo de inactividade mínimo.
Liberar e emitir un enderezo IP virtual é unha operación barata e rápida.
Para traballar con VIP, necesitas acceso ao servidor a través de SSH ou o uso de utilidades especiais, por exemplo, keepalived.

Vexamos posibles problemas co noso asistente e imaxinemos como debería funcionar o mecanismo de recuperación automática.

A conectividade de rede co mestre desapareceu ou xurdiu un problema a nivel de hardware e o servidor non está dispoñible

O orquestrator actualiza a topoloxía do clúster, cada réplica indica que o mestre non está dispoñible. O orquestrador inicia o proceso de selección dunha réplica adecuada para o papel do novo mestre e comeza a recuperación.
Estamos tentando eliminar o VIP do antigo mestre, sen éxito.
A réplica cambia ao papel de mestre. A topoloxía está a ser reconstruída.
Engadindo unha nova interface de rede con VIP. Como non foi posible eliminar o VIP, comezamos a enviar periodicamente unha solicitude en segundo plano ARP gratuíto. Este tipo de solicitude/resposta permítelle actualizar a táboa de asignación de enderezos IP e MAC nos switches conectados, notificándolle así que o noso VIP se mudou. Isto minimiza a probabilidade split brain ao devolver o vello mestre.
Todas as novas conexións son redirixidas inmediatamente ao novo mestre. As conexións antigas fallan e as chamadas repetidas á base de datos realízanse a nivel de aplicación.

O servidor está a funcionar en modo normal, produciuse un fallo a nivel de DBMS

O algoritmo é semellante ao caso anterior: actualizar a topoloxía e iniciar o proceso de recuperación. Dado que o servidor está dispoñible, liberamos con éxito o VIP no mestre antigo, transferímolo ao novo e enviamos varias solicitudes ARP. A posible devolución do antigo mestre non debería afectar ao clúster reconstruído nin ao funcionamento da aplicación.

Outros problemas

Fallo de réplicas ou mestres intermedios non conduce a accións automáticas e require intervención manual.

Sempre se engade temporalmente unha interface de rede virtual, é dicir, despois do reinicio do servidor, o VIP non se asigna automaticamente. Cada instancia de base de datos comeza en modo de só lectura por defecto, o orquestrator cambia automaticamente o novo mestre para escribir e tenta instalar read only sobre o vello mestre. Estas accións están dirixidas a reducir a probabilidade split brain.

Poden xurdir problemas durante o proceso de recuperación, que tamén se debe notificar a través da IU do orquestrator ademais das ferramentas de seguimento estándar. Ampliamos a API REST engadindo esta función (PR actualmente en revisión).

O diagrama xeral da solución HA preséntase a continuación.

Elixir un novo mestre

O orquestrador é o suficientemente intelixente e tenta escoller a réplica máis adecuada como novo mestre segundo os seguintes criterios:

a réplica queda atrás do mestre;
Versión de MySQL do mestre e da réplica;
tipo de replicación (RBR, SBR ou mixta);
localización no mesmo ou en diferentes centros de datos;
dispoñibilidade errant GTID — transaccións que se executaron na réplica e non están no mestre;
tamén se teñen en conta as regras de selección personalizadas.

Non todas as indicacións son un candidato ideal para un mestre. Por exemplo, pódese usar unha réplica para facer copias de seguridade de datos ou o servidor ten unha configuración de hardware máis débil. Orquestrador soportes regras manuais coas que podes personalizar as túas preferencias de selección de candidatos desde o máis preferido ata o ignorado.

Tempo de resposta e recuperación

No caso de producirse un incidente, é importante minimizar o tempo de inactividade do sistema, polo que consideremos os parámetros de MySQL que afectan á creación e actualización da topoloxía do clúster por parte do orquestrador:

slave_net_timeout — o número de segundos durante os que a réplica espera a que cheguen novos datos ou un sinal de latido do mestre antes de que se recoñeza a conexión como perdida e se volva conectar. Canto menor sexa o valor, máis rápido pode determinar a réplica que a comunicación co mestre está rota. Establecemos este valor en 5 segundos.
MASTER_CONNECT_RETRY — número de segundos entre os intentos de reconexión. En caso de problemas de rede, un valor baixo para este parámetro permitirá a conexión rápida e evitará que se inicie o proceso de recuperación do clúster. O valor recomendado é de 1 segundo.
MASTER_RETRY_COUNT — número máximo de intentos de reconexión.
MASTER_HEARTBEAT_PERIOD — intervalo en segundos despois do cal o mestre envía un sinal de latido cardíaco. O valor predeterminado é a metade slave_net_timeout.

Opcións do orquestrator:

DelayMasterPromotionIfSQLThreadNotUpToDate - se é igual true, entón o rol mestre non se aplicará á réplica candidata ata que o fío SQL da réplica complete todas as transaccións non aplicadas do rexistro de retransmisión. Usamos esta opción para evitar perder transaccións cando todas as réplicas candidatas quedan atrás.
InstancePollSeconds — Frecuencia de construción e actualización da topoloxía.
RecoveryPollSeconds - Frecuencia da análise da topoloxía. Se se detecta un problema, iníciase a recuperación da topoloxía. Isto constante, igual a 1 segundo.

Cada nodo do clúster é sondeado polo orquestrator unha vez cada vez InstancePollSeconds segundos Cando se detecta un problema, o estado do clúster é forzado actualizado, e despois tómase a decisión final de realizar a recuperación. Ao experimentar con diferentes parámetros da base de datos e do orquestrador, puidemos reducir o tempo de resposta e recuperación a 30 segundos.

Banco de probas

Comezamos a probar o esquema HA co desenvolvemento dun local banco de probas e posterior implementación en ambientes de proba e produción. O stand local está totalmente automatizado baseado en Docker e permítelle experimentar coa configuración do orquestrador e da rede, escalar o clúster de 2 a 3 servidores a varias ducias e realizar exercicios nun ambiente seguro.

Durante os exercicios, escollemos un dos métodos de emulación de problemas: disparar ao mestre ao instante kill -9, finaliza suavemente o proceso e detén o servidor (docker-compose stop), simular problemas de rede usando iptables -j REJECT ou iptables -j DROP. Agardamos os seguintes resultados:

o orquestrator detectará problemas co mestre e actualizará a topoloxía en non máis de 10 segundos;
o procedemento de recuperación comezará automaticamente: a configuración da rede cambiará, o papel do mestre pasará á réplica, a topoloxía reconstruirase;
o novo mestre será escribible, as réplicas en directo non se perderán durante o proceso de reconstrución;
comezarán a escribirse os datos no novo mestre e replicaranse;
O tempo total de recuperación non será superior a 30 segundos.

Como sabes, o sistema pode comportarse de forma diferente en contornas de proba e produción debido a diferentes configuracións de hardware e rede, diferenzas na carga sintética e real, etc. Por iso, realizamos periodicamente exercicios en condicións reais, comprobando como se comporta o sistema cando se perde a conectividade da rede ou se degradan as súas partes individuais. No futuro, queremos construír unha infraestrutura completamente idéntica para ambos os ambientes e automatizar as súas probas.

Descubrimentos

A saúde do nodo do sistema de almacenamento principal é unha das principais tarefas do equipo de operacións e SRE. A implementación do orquestrator e da solución HA baseada en VIP permitiunos acadar os seguintes resultados:

detección fiable de problemas coa topoloxía do clúster de bases de datos;
resposta automática e rápida a incidentes relacionados co mestre, reducindo o tempo de inactividade do sistema.

Non obstante, a solución ten as súas limitacións e inconvenientes:

escalar o esquema HA a varios centros de datos requirirá unha única rede L2 entre eles;
Antes de asignarlle VIP ao novo mestre, necesitamos liberalo no antigo. O proceso é secuencial, o que aumenta o tempo de recuperación;
liberar o VIP require acceso SSH ao servidor ou calquera outro método de chamar a procedementos remotos. Dado que o servidor ou a base de datos está experimentando problemas que causaron o proceso de recuperación, non podemos estar seguros de que a eliminación de VIP se complete correctamente. E isto pode provocar a aparición de dous servidores co mesmo enderezo IP virtual e un problema split brain.

Evitar split brain, podes usar o método STONITH ("Dispara ao outro nodo na cabeza"), que illa ou desactiva completamente o nodo problemático. Hai outras formas de implementar a alta dispoñibilidade do clúster: unha combinación de VIP e DNS, servizos de descubrimento de servizos e proxy, replicación síncrona e outros métodos que teñen as súas propias desvantaxes e vantaxes.

Falei sobre o noso enfoque para crear un clúster de conmutación por falla de MySQL. É doado de implementar e ofrece un nivel aceptable de fiabilidade nas condicións actuais. A medida que se desenvolva todo o sistema en xeral e as infraestruturas en particular, este enfoque evolucionará sen dúbida.

Fonte: www.habr.com

Orquestrator e VIP como solución de alta disponibilidad para un clúster MySQL