In Citymobil usemu una basa di dati MySQL cum'è u nostru principale almacenamentu di dati persistenti. Avemu parechji clusters di basa di dati per diversi servizii è scopi.

A dispunibilità constante di u maestru hè un indicatore criticu di u funziunamentu di tuttu u sistema è e so parti individuali. A ricuperazione automatica di u cluster in casu di un fallimentu maestru riduce assai u tempu di risposta à l'incidentu è u tempu di inattività di u sistema. In questu articulu, fighjeraghju un disignu di alta dispunibilità (HA) per un cluster MySQL basatu nantu MySQL Orchestrator è indirizzi IP virtuali (VIP).

Soluzione HA basata nantu à VIP

Prima, vi dicu brevemente quale hè u nostru sistema di almacenamiento di dati.

Utilizemu un schema di replicazione classica cù un maestru accessibile in scrittura è parechje repliche di sola lettura. Un cluster pò cuntene un maestru intermediu - un node chì hè à tempu una replica è un maestru per l'altri. I clienti accedenu à e rèpliche attraversu HAProxy, chì permette una distribuzione uniforme di carica è una scala faciule. L'usu di HAProxy hè dovutu à ragioni storichi, è simu attualmente in u prucessu di migrazione à ProxySQL.

A replicazione hè realizata in modu semi-sincronu basatu nantu GTID. Questu significa chì almenu una replica deve logà una transazzione prima ch'ella sia cunsiderata successu. Stu modu di replicazione furnisce un equilibriu ottimale trà u rendiment è a sicurità di dati in casu di fallimentu di u nodu maestru. In fondu, tutti i cambiamenti sò trasferiti da u maestru à e repliche chì utilizanu Row Based Replication (RBR), ma certi nodi pò avè mixed binlog format.

L'orchestratore aghjurnà periodicamente u statu di a topologia di u cluster, analizà l'infurmazioni ricevuti, è, se i prublemi, ponu lancià un prucessu di ricuperazione automatica. U sviluppatore hè rispunsevuli di a prucedura stessu, postu chì pò esse implementatu in diverse manere: basatu annantu à VIP, DNS, utilizendu servizii di scuperta di serviziu o miccanismi auto-scritti.

Un modu simplice per restaurà un maestru si falla hè di utilizà indirizzi VIP flottanti.

Ciò chì avete bisognu di sapè di sta suluzione prima di avanzà:

• Un VIP hè un indirizzu IP chì ùn hè micca assuciatu cù una interfaccia di rete fisica specifica. Se un node falla o durante u mantenimentu programatu, pudemu cambià u VIP à una altra risorsa cù un minimu downtime.
• A liberazione è l'emissione di un indirizzu IP virtuale hè una operazione economica è rapida.
• Per travaglià cù VIP, avete bisognu di accessu à u servitore via SSH, o l'usu di utilità speciale, per esempiu, keepalived.

Fighjemu i prublemi pussibuli cù u nostru mago è imagine cumu u mecanismu di ricuperazione automatica duverà travaglià.

A cunnessione di a rete à u maestru hè sparita, o un prublema hè ghjuntu à u livellu di hardware, è u servitore ùn hè micca dispunibule

1. L'orchestratore aghjurnà a topologia di u cluster, ogni replica informa chì u maestru ùn hè micca dispunibule. L'orchestratore principia u prucessu di selezzione di una replica adattata per u rolu di u novu maestru è principia a ricuperazione.
2. Avemu pruvatu à caccià u VIP da u vechju maestru - senza successu.
3. A replica cambia à u rolu di maestru. A topologia hè stata ricustruita.
4. Aghjunghjendu una nova interfaccia di rete cù VIP. Siccomu ùn era micca pussibule di caccià u VIP, cuminciamu à mandà periodicamente una dumanda in fondo ARP gratuitu. Stu tipu di dumanda / risposta permette di aghjurnà a tabella di mappatura di l'indirizzu IP è MAC nantu à i switches cunnessi, avvisendu cusì chì u nostru VIP s'hè spustatu. Questu minimizza a probabilità split brain quand'ellu torna u vechju maestru.
5. Tutte e novi cunnessione sò immediatamente rediretti à u novu maestru. I vechji cunnessione fallenu è i chjami ripetuti à a basa di dati sò fatti à u livellu di l'applicazione.

U servitore opera in modu normale, un fallimentu hè accadutu à u livellu DBMS

L'algoritmu hè simile à u casu precedente: aghjurnà a topologia è principià u prucessu di ricuperazione. Siccomu u servitore hè dispunibule, liberemu successu u VIP nantu à u vechju maestru, trasfiriu à u novu, è mandà parechje dumande ARP. U pussibule ritornu di u vechju maestru ùn deve micca affettà u cluster ricustruitu è ​​u funziunamentu di l'applicazione.

Altri prublemi

Fiascu di repliche o maestri intermedi ùn porta micca à l'azzioni automatica è richiede intervenzione manuale.

Una interfaccia di rete virtuale hè sempre aghjuntu temporaneamente, vale à dì, dopu à un reboot di u servitore, u VIP ùn hè micca automaticamente assignatu. Ogni istanza di basa di dati principia in modu di sola lettura per difettu, l'orchestratore cambia automaticamente u novu maestru per scrive è prova à stallà. read only nantu à u vechju maestru. Queste azioni sò destinate à riduce a probabilità split brain.

I prublemi ponu accade durante u prucessu di ricuperazione, chì deve ancu esse notificatu per mezu di l'UI di l'orchestratore in più di e strumenti di monitoraghju standard. Avemu allargatu l'API REST aghjustendu sta funzione (PR attualmente in esame).

U schema generale di a suluzione HA hè presentata quì sottu.

Sceglie un novu maestru

L'orchestratore hè abbastanza intelligente è prova di sceglie a replica più adatta cum'è un novu maestru secondu i criteri seguenti:

• a replica lags daretu à u maestru;
• Versione MySQL di maestru è replica;
• tipu di replicazione (RBR, SBR o mista);
• locu in u listessu o differente centri di dati;
• dispunibilità errant GTID - transazzioni chì sò stati eseguiti nantu à a replica è ùn sò micca nantu à u maestru;
• regule di selezzione persunalizata sò ancu cunsiderate.

Ùn ogni cue hè un candidatu ideale per un maestru. Per esempiu, una replica pò esse usata per a copia di salvezza di dati, o u servitore hà una cunfigurazione hardware più debule. Orchestratore sustegnu regule manuale cù quale pudete persunalizà e vostre preferenze di selezzione di candidati da u più preferitu à ignuratu.

Tempu di risposta è di ricuperazione

In casu d'un incidente, hè impurtante di minimizzà i tempi di inattività di u sistema, cusì cunsideremu i paràmetri MySQL chì afectanu a creazione è l'aghjurnamentu di a topologia di cluster da l'orchestratore:

• slave_net_timeout - u numeru di sicondi durante i quali a replica aspetta chì novi dati o un signalu di battimentu di u core per arrivà da u maestru prima chì a cunnessione hè ricunnisciuta cum'è persa è ricollegata. U più bassu u valore, u più veloce a replica pò determinà chì a cumunicazione cù u maestru hè rottu. Fixemu stu valore à 5 seconde.
• MASTER_CONNECT_RETRY - numeru di seconde trà i tentativi di ricunnessione. In casu di prublemi di rete, un valore bassu per stu paràmetru permetterà una ricunsione rapida è impedisce u prucessu di ricuperazione di u cluster da inizià. U valore cunsigliatu hè 1 secondu.
• MASTER_RETRY_COUNT - numeru massimu di tentativi di ricollegamentu.
• MASTER_HEARTBEAT_PERIOD - intervallu in seconde dopu chì u maestru manda un signalu di battitu di u core. Defaults à a mità di u valore slave_net_timeout.

Opzioni di l'orchestratore:

• DelayMasterPromotionIfSQLThreadNotUpToDate - si uguali true, allura u rolu maestru ùn serà micca appiicatu nantu à a replica candidata finu à chì u filu SQL di a replica hà cumpletu tutte e transazzione micca applicate da u Relay Log. Utilizemu sta opzione per evità di perde transazzione quandu tutte e rèpliche di i candidati fallenu.
• InstancePollSeconds - frequenza di custruisce è aghjurnà a topologia.
• RecoveryPollSeconds - frequenza di l'analisi di topologia. Se un prublema hè rilevatu, a ricuperazione di a topologia hè iniziata. Questu costante, uguale à 1 seconde.

Ogni node di cluster hè sondatu da l'orchestratore una volta ogni InstancePollSeconds seconde Quandu un prublema hè rilevatu, u statu di cluster hè furzatu aghjurnatu, è dopu a decisione finale hè fatta per fà a ricuperazione. Sperimentendu cù diversi parametri di basa di dati è orchestratori, pudemu riduce u tempu di risposta è di ricuperazione à 30 seconde.

banc d'essai

Avemu cuminciatu à pruvà u schema HA cù u sviluppu di un locu banc d'essai è ulteriore implementazione in ambienti di prova è di produzzione. U stand lucale hè cumplettamente automatizatu basatu in Docker è vi permette di sperimentà a cunfigurazione di l'orchestratore è a rete, scala u cluster da 2-3 servitori à parechje decine, è fà esercizii in un ambiente sicuru.

Durante l'esercizii, scegliemu unu di i metudi di emulazione di u prublema: sparà istantaneamente u maestru usendu kill -9, finisce dolcemente u prucessu è ferma u servitore (docker-compose stop), simulate i prublemi di rete cù l'usu iptables -j REJECT o iptables -j DROP. Aspittemu i seguenti risultati:

• l'orchestratore detecterà prublemi cù u maestru è aghjurnà a topologia in micca più di 10 seconde;
• a prucedura di ricuperazione inizierà automaticamente: a cunfigurazione di a rete cambierà, u rolu di u maestru passà à a replica, a topologia serà ricustruita;
• u novu maestru diventerà scrivibile, rèpliche in diretta ùn saranu micca persu durante u prucessu di ricustruzzione;
• i dati cumincianu à esse scritti à u novu maestru è riplicate;
• U tempu tutale di ricuperazione ùn serà micca più di 30 seconde.

Comu sapete, u sistema pò cumportà in modu diversu in l'ambienti di teste è di produzzione per via di e diverse configurazioni di hardware è di rete, differenze in carica sintetica è reale, etc. Per quessa, facemu periodicamente esercizii in cundizioni reali, cuntrollà cumu si cumporta u sistema quandu a cunnessione di a rete hè persa o e so parti individuali sò degradate. In u futuru, vulemu custruisce una infrastruttura completamente identica per i dui ambienti è automatizà a so prova.

scuperti

A salute di u node di u sistema di almacenamentu principale hè unu di i travaglii principali di u SRE è u squadra di l'operazioni. L'implementazione di l'orchestratore è a suluzione HA basata nantu à VIP ci hà permessu di ottene i seguenti risultati:

• rilevazione affidabile di prublemi cù a topologia di u cluster di basa di dati;
• Risposta automatica è rapida à incidenti maestri, riducendu i tempi di inattività di u sistema.

Tuttavia, a suluzione hà i so limitazioni è svantaghji:

• scalendu u schema HA à parechji centri di dati necessitarà una sola reta L2 trà elli;
• Prima di assignà VIP à u novu maestru, avemu bisognu di liberà nantu à u vechju. U prucessu hè sequenziale, chì aumenta u tempu di ricuperazione;
• A liberazione di u VIP richiede un accessu SSH à u servitore, o qualsiasi altru mètudu di chjamà e prucedure remoti. Siccomu u servitore o a basa di dati hà avutu prublemi chì anu causatu u prucessu di ricuperazione, ùn pudemu micca esse sicuru chì a rimozione di VIP hà da esse cumpletu cù successu. È questu pò purtà à l'apparizione di dui servitori cù u stessu indirizzu IP virtuale è un prublema split brain.

Per evitari split brain, pudete aduprà u metudu STONITH ("Shoot The Other Node In The Head"), chì isola completamente o disattiva u node problema. Ci sò altre manere di implementà cluster alta dispunibilità: una cumminazione di VIP è DNS, servizii di scuperta di serviziu è proxy, replicazione sincrona è altri metudi chì anu i so svantaghji è vantaghji.

Aghju parlatu di u nostru approcciu per creà un cluster di failover MySQL. Hè faciule da implementà è furnisce un livellu accettabile di affidabilità in e cundizioni attuali. Cum'è u sistema sanu in generale è l'infrastruttura in particulare si sviluppanu, questu approcciu svilupperà senza dubbitu.

Source: www.habr.com