A Citymobil fem servir una base de dades MySQL com a principal emmagatzematge de dades persistents. Tenim diversos clústers de bases de dades per a diversos serveis i finalitats.

La disponibilitat constant del mestre és un indicador crític del rendiment de tot el sistema i les seves parts individuals. La recuperació automàtica del clúster en cas d'error principal redueix molt el temps de resposta a incidents i el temps d'inactivitat del sistema. En aquest article, miraré un disseny d'alta disponibilitat (HA) per a un clúster MySQL basat en MySQL Orchestrator i adreces IP virtuals (VIP).

Solució HA basada en VIP

En primer lloc, us explicaré breument quin és el nostre sistema d'emmagatzematge de dades.

Utilitzem un esquema de replicació clàssic amb un mestre accessible per a escriptura i diverses rèpliques de només lectura. Un clúster pot contenir un mestre intermedi: un node que és alhora una rèplica i un mestre per als altres. Els clients accedeixen a les rèpliques mitjançant HAProxy, que permet una distribució uniforme de la càrrega i un escalat fàcil. L'ús d'HAProxy es deu a motius històrics i actualment estem en procés de migració a ProxySQL.

La replicació es realitza en mode semisíncron basat en GTID. Això vol dir que almenys una rèplica ha de registrar una transacció abans que es consideri reeixida. Aquest mode de replicació proporciona un equilibri òptim entre el rendiment i la seguretat de les dades en cas d'error del node mestre. Bàsicament, tots els canvis es transfereixen del mestre a les rèpliques utilitzant Row Based Replication (RBR), però alguns nodes poden tenir mixed binlog format.

L'orquestrador actualitza periòdicament l'estat de la topologia del clúster, analitza la informació rebuda i, si sorgeixen problemes, pot iniciar un procediment de recuperació automàtica. El desenvolupador és el responsable del procediment en si, ja que es pot implementar de diferents maneres: basant-se en VIP, DNS, utilitzant serveis de descoberta de serveis o mecanismes auto-escrits.

Una manera senzilla de restaurar un mestre si falla és utilitzar adreces VIP flotants.

Què necessiteu saber sobre aquesta solució abans de seguir endavant:

• Un VIP és una adreça IP que no està associada a una interfície de xarxa física específica. Si un node falla o durant el manteniment programat, podem canviar el VIP a un altre recurs amb un temps d'inactivitat mínim.
• Alliberar i emetre una adreça IP virtual és una operació barata i ràpida.
• Per treballar amb VIP, necessiteu accés al servidor mitjançant SSH o l'ús d'utilitats especials, per exemple, keepalived.

Vegem els possibles problemes amb el nostre assistent i imaginem com hauria de funcionar el mecanisme de recuperació automàtica.

La connectivitat de xarxa amb el mestre ha desaparegut o s'ha produït un problema a nivell de maquinari i el servidor no està disponible

1. L'orquestrador actualitza la topologia del clúster, cada rèplica informa que el mestre no està disponible. L'orquestrador inicia el procés de selecció d'una rèplica adequada per al rol del nou mestre i comença la recuperació.
2. Estem intentant eliminar el VIP de l'antic mestre, sense èxit.
3. La rèplica canvia al paper de mestre. S'està reconstruint la topologia.
4. Afegeix una nova interfície de xarxa amb VIP. Com que no va ser possible eliminar el VIP, comencem a enviar periòdicament una sol·licitud en segon pla ARP gratuït. Aquest tipus de sol·licitud/resposta us permet actualitzar la taula de mapatge d'adreces IP i MAC als commutadors connectats, notificant-vos així que el nostre VIP s'ha mogut. Això minimitza la probabilitat split brain en tornar el vell mestre.
5. Totes les connexions noves es redirigiran immediatament al nou mestre. Les connexions antigues fallen i es fan trucades repetides a la base de dades a nivell d'aplicació.

El servidor funciona en mode normal, s'ha produït una fallada a nivell de DBMS

L'algorisme és similar al cas anterior: actualitzar la topologia i iniciar el procés de recuperació. Com que el servidor està disponible, alliberem correctament el VIP a l'antic mestre, el transferim al nou i enviem diverses sol·licituds ARP. El possible retorn de l'antic mestre no hauria d'afectar el clúster reconstruït i el funcionament de l'aplicació.

Altres problemes

Falla de rèpliques o màsters intermedis no condueix a accions automàtiques i requereix intervenció manual.

Una interfície de xarxa virtual sempre s'afegeix temporalment, és a dir, després d'un reinici del servidor, el VIP no s'assigna automàticament. Cada instància de base de dades s'inicia en mode de només lectura de manera predeterminada, l'orquestrador canvia automàticament el nou mestre per escriure i intenta instal·lar-lo. read only sobre el vell mestre. Aquestes accions tenen com a objectiu reduir la probabilitat split brain.

Es poden produir problemes durant el procés de recuperació, que també s'ha de notificar a través de la interfície d'usuari de l'orquestrador, a més de les eines de supervisió estàndard. Hem ampliat l'API REST afegint aquesta característica (PR actualment en revisió).

A continuació es presenta el diagrama general de la solució HA.

Escollir un nou mestre

L'orquestrador és prou intel·ligent i intenta triar la rèplica més adequada com a nou màster d'acord amb els criteris següents:

• la rèplica queda endarrerida del mestre;
• Versió MySQL de mestre i rèplica;
• tipus de replicació (RBR, SBR o mixta);
• ubicació al mateix centre de dades o diferents;
• disponibilitat errant GTID — transaccions que s'han executat a la rèplica i no es troben al mestre;
• també es tenen en compte les regles de selecció personalitzades.

No totes les indicacions són un candidat ideal per a un màster. Per exemple, es pot utilitzar una rèplica per fer còpies de seguretat de dades o el servidor té una configuració de maquinari més feble. Orquestrador suports regles manuals amb les quals podeu personalitzar les preferències de selecció de candidats des del més preferit fins a l'ignorat.

Temps de resposta i recuperació

En cas d'incidència, és important minimitzar el temps d'inactivitat del sistema, així que considerem els paràmetres de MySQL que afecten la creació i actualització de la topologia del clúster per part de l'orquestrador:

• slave_net_timeout — el nombre de segons durant els quals la rèplica espera que arribin dades noves o un senyal de batec del cor del mestre abans que la connexió es reconegui com a perduda i es torni a connectar. Com més baix sigui el valor, més ràpidament la rèplica pot determinar que la comunicació amb el mestre està trencada. Posem aquest valor a 5 segons.
• MASTER_CONNECT_RETRY — nombre de segons entre intents de reconnexió. En cas de problemes de xarxa, un valor baix per a aquest paràmetre permetrà una connexió ràpida i evitarà que s'iniciï el procés de recuperació del clúster. El valor recomanat és d'1 segon.
• MASTER_RETRY_COUNT — nombre màxim d'intents de reconnexió.
• MASTER_HEARTBEAT_PERIOD — interval en segons després del qual el mestre envia un senyal de batec. Per defecte, la meitat del valor slave_net_timeout.

Paràmetres de l'orquestrador:

• DelayMasterPromotionIfSQLThreadNotUpToDate - si és igual true, aleshores el rol mestre no s'aplicarà a la rèplica candidata fins que el fil SQL de la rèplica hagi completat totes les transaccions no aplicades del registre de retransmissió. Utilitzem aquesta opció per evitar perdre transaccions quan totes les rèpliques candidates es queden enrere.
• InstancePollSeconds — freqüència de construcció i actualització de la topologia.
• RecoveryPollSeconds — freqüència d'anàlisi de topologia. Si es detecta un problema, s'inicia la recuperació de la topologia. Això constant, igual a 1 segon.

Cada node del clúster és consultat per l'orquestrador una vegada cada InstancePollSeconds segons Quan es detecta un problema, l'estat del clúster es força actualitzat, i després es pren la decisió final de realitzar la recuperació. Experimentant amb diferents paràmetres de base de dades i orquestrador, vam poder reduir el temps de resposta i recuperació a 30 segons.

banc de proves

Vam començar a provar l'esquema HA amb el desenvolupament d'un local Banc de proves i posterior implementació en entorns de prova i producció. L'estand local està totalment automatitzat basat en Docker i us permet experimentar amb la configuració de l'orquestrador i la xarxa, escalar el clúster de 2 a 3 servidors a diverses dotzenes i realitzar exercicis en un entorn segur.

Durant els exercicis, escollim un dels mètodes d'emulació de problemes: disparar a l'instant el mestre utilitzant kill -9, finalitzeu suaument el procés i atureu el servidor (docker-compose stop), simular problemes de xarxa utilitzant iptables -j REJECT o iptables -j DROP. Esperem els següents resultats:

• l'orquestrador detectarà problemes amb el mestre i actualitzarà la topologia en no més de 10 segons;
• el procediment de recuperació s'iniciarà automàticament: la configuració de la xarxa canviarà, el paper del mestre passarà a la rèplica, la topologia es reconstruirà;
• el nou mestre es podrà escriure, les rèpliques en directe no es perdran durant el procés de reconstrucció;
• Les dades es començaran a escriure al nou mestre i es replicaran;
• El temps total de recuperació no serà superior a 30 segons.

Com sabeu, el sistema pot comportar-se de manera diferent en entorns de prova i producció a causa de diferents configuracions de maquinari i xarxa, diferències de càrrega sintètica i real, etc. Per tant, periòdicament realitzem exercicis en condicions reals, comprovant com es comporta el sistema quan es perd la connectivitat de la xarxa o es degraden les seves parts individuals. En el futur, volem construir una infraestructura completament idèntica per als dos entorns i automatitzar-ne les proves.

Troballes

La salut del node del sistema d'emmagatzematge principal és un dels objectius principals de l'SRE i l'equip d'operacions. La implementació de l'orquestrator i la solució HA basada en VIP ens va permetre aconseguir els següents resultats:

• detecció fiable de problemes amb la topologia del clúster de bases de dades;
• resposta automàtica i ràpida a incidències relacionades amb el mestre, reduint el temps d'inactivitat del sistema.

Tanmateix, la solució té les seves limitacions i desavantatges:

• escalar l'esquema HA a diversos centres de dades requerirà una única xarxa L2 entre ells;
• Abans d'assignar VIP al nou mestre, hem de llançar-lo a l'antic. El procés és seqüencial, la qual cosa augmenta el temps de recuperació;
• alliberar el VIP requereix accés SSH al servidor o qualsevol altre mètode per cridar procediments remots. Com que el servidor o la base de dades està experimentant problemes que van provocar el procés de recuperació, no podem estar segurs que l'eliminació de VIP es completi correctament. I això pot provocar l'aparició de dos servidors amb la mateixa adreça IP virtual i un problema split brain.

Evitar split brain, podeu utilitzar el mètode STONITH ("Dispara a l'altre node al cap"), que aïlla completament o desactiva el node problemàtic. Hi ha altres maneres d'implementar l'alta disponibilitat del clúster: una combinació de VIP i DNS, serveis de descobriment de serveis i proxy, replicació síncrona i altres mètodes que tenen els seus propis desavantatges i avantatges.

Vaig parlar del nostre enfocament per crear un clúster de migració per error de MySQL. És fàcil d'implementar i proporciona un nivell acceptable de fiabilitat en les condicions actuals. A mesura que es desenvolupi tot el sistema en general i la infraestructura en particular, aquest enfocament evolucionarà sens dubte.

Font: www.habr.com