La Citymobil folosim o bază de date MySQL ca principală stocare a datelor persistente. Avem mai multe clustere de baze de date pentru diverse servicii și scopuri.

Disponibilitatea constantă a masterului este un indicator critic al performanței întregului sistem și a părților sale individuale. Recuperarea automată a clusterului în cazul unei defecțiuni master reduce foarte mult timpul de răspuns la incident și timpul de nefuncționare a sistemului. În acest articol, voi analiza un design de înaltă disponibilitate (HA) pentru un cluster MySQL bazat pe MySQL Orchestrator și adrese IP virtuale (VIP).

Soluție HA bazată pe VIP

În primul rând, vă voi spune pe scurt care este sistemul nostru de stocare a datelor.

Folosim o schemă de replicare clasică cu un master accesibil în scriere și mai multe replici numai pentru citire. Un cluster poate conține un master intermediar - un nod care este atât o replică, cât și un master pentru alții. Clienții accesează replicile prin HAProxy, ceea ce permite distribuirea uniformă a încărcăturii și scalarea ușoară. Utilizarea HAProxy se datorează unor motive istorice, iar în prezent suntem în proces de migrare la ProxySQL.

Replicarea se realizează în modul semi-sincron pe baza GTID. Aceasta înseamnă că cel puțin o replică trebuie să înregistreze o tranzacție înainte ca aceasta să fie considerată reușită. Acest mod de replicare oferă un echilibru optim între performanță și siguranța datelor în cazul unei defecțiuni a nodului principal. Practic, toate modificările sunt transferate de la master la replici folosind Row Based Replication (RBR), dar unele noduri pot avea mixed binlog format.

Orchestratorul actualizează periodic starea topologiei clusterului, analizează informațiile primite și, dacă apar probleme, poate lansa o procedură de recuperare automată. Dezvoltatorul este responsabil pentru procedura în sine, deoarece aceasta poate fi implementată în diferite moduri: pe baza VIP, DNS, folosind servicii de descoperire a serviciilor sau mecanisme auto-scrise.

O modalitate simplă de a restaura un master dacă nu reușește este să folosești adrese VIP flotante.

Ce trebuie să știți despre această soluție înainte de a merge mai departe:

• Un VIP este o adresă IP care nu este asociată cu o anumită interfață fizică de rețea. Dacă un nod eșuează sau în timpul întreținerii programate, putem comuta VIP-ul pe o altă resursă cu un timp de nefuncționare minim.
• Eliberarea și emiterea unei adrese IP virtuale este o operațiune ieftină și rapidă.
• Pentru a lucra cu VIP, aveți nevoie de acces la server prin SSH sau de utilizarea unor utilități speciale, de exemplu, keepalived.

Să ne uităm la posibilele probleme cu vrăjitorul nostru și să ne imaginăm cum ar trebui să funcționeze mecanismul de recuperare automată.

Conexiunea la rețea la master a dispărut sau a apărut o problemă la nivel hardware și serverul este indisponibil

1. Orchestratorul actualizează topologia clusterului, fiecare replică raportează că masterul este indisponibil. Orchestratorul începe procesul de selectare a unei replici potrivite pentru rolul noului maestru și începe recuperarea.
2. Încercăm să scoatem VIP-ul din vechiul maestru - fără succes.
3. Replica trece la rolul de maestru. Topologia este în curs de reconstrucție.
4. Adăugarea unei noi interfețe de rețea cu VIP. Deoarece nu a fost posibilă eliminarea VIP-ului, începem să trimitem periodic o solicitare în fundal ARP gratuit. Acest tip de cerere/răspuns vă permite să actualizați tabelul de mapare a adreselor IP și MAC de pe switch-urile conectate, notificându-vă astfel că VIP-ul nostru s-a mutat. Acest lucru minimizează probabilitatea split brain la întoarcerea bătrânului stăpân.
5. Toate conexiunile noi sunt imediat redirecționate către noul master. Conexiunile vechi eșuează și apelurile repetate la baza de date sunt efectuate la nivel de aplicație.

Serverul funcționează în modul normal, a avut loc o eroare la nivelul SGBD

Algoritmul este similar cu cazul precedent: actualizarea topologiei și începerea procesului de recuperare. Deoarece serverul este disponibil, lansăm cu succes VIP-ul pe vechiul master, îl transferăm pe cel nou și trimitem mai multe solicitări ARP. Posibila revenire a vechiului master nu ar trebui să afecteze clusterul reconstruit și funcționarea aplicației.

Alte probleme

Eșecul replicilor sau masterilor intermediari nu conduce la acțiuni automate și necesită intervenție manuală.

O interfață de rețea virtuală este întotdeauna adăugată temporar, adică după o repornire a serverului, VIP-ul nu este atribuit automat. Fiecare instanță de bază de date pornește în mod implicit doar citire, orchestratorul comută automat noul master la scriere și încearcă să instaleze read only pe bătrânul maestru. Aceste acțiuni sunt menite să reducă probabilitatea split brain.

Pot apărea probleme în timpul procesului de recuperare, care ar trebui notificat și prin interfața de utilizare a orchestratorului, pe lângă instrumentele standard de monitorizare. Am extins API-ul REST adăugând această caracteristică (PR în prezent în curs de revizuire).

Diagrama generală a soluției HA este prezentată mai jos.

Alegerea unui nou maestru

Orchestratorul este destul de inteligent și încearcă să aleagă replica cea mai potrivită ca nou maestru conform următoarelor criterii:

• replica rămâne în urma maestrului;
• Versiunea MySQL de master și replica;
• tip de replicare (RBR, SBR sau mixt);
• locație în același sau în centre de date diferite;
• disponibilitate errant GTID — tranzacții care au fost executate pe replică și nu sunt pe master;
• sunt de asemenea luate în considerare regulile de selecție personalizate.

Nu orice indiciu este un candidat ideal pentru un maestru. De exemplu, o replică poate fi folosită pentru a face backup la date sau serverul are o configurație hardware mai slabă. Orchestrator suporturi reguli manuale cu ajutorul cărora vă puteți personaliza preferințele de selecție a candidaților de la cele mai preferate la cele ignorate.

Timp de răspuns și recuperare

În cazul unui incident, este important să minimizați timpul de nefuncționare a sistemului, așa că să luăm în considerare parametrii MySQL care afectează crearea și actualizarea topologiei clusterului de către orchestrator:

• slave_net_timeout — numărul de secunde în care replica așteaptă să sosească date noi sau un semnal de bătăi inimii de la master înainte ca conexiunea să fie recunoscută ca pierdută și reconectată. Cu cât valoarea este mai mică, cu atât replica poate determina mai rapid că comunicarea cu maestrul este întreruptă. Setăm această valoare la 5 secunde.
• MASTER_CONNECT_RETRY — numărul de secunde între încercările de reconectare. În cazul unor probleme de rețea, o valoare scăzută pentru acest parametru va permite reconectarea rapidă și va împiedica începerea procesului de recuperare a clusterului. Valoarea recomandată este de 1 secundă.
• MASTER_RETRY_COUNT — numărul maxim de încercări de reconectare.
• MASTER_HEARTBEAT_PERIOD — interval în secunde după care comandantul trimite un semnal de bătăi inimii. Implicit la jumătate din valoare slave_net_timeout.

Parametrii orchestratorului:

• DelayMasterPromotionIfSQLThreadNotUpToDate - dacă sunt egale true, atunci rolul principal nu va fi aplicat pe replica candidată până când firul de execuție SQL al replicii nu a finalizat toate tranzacțiile neaplicate din jurnalul de retransmisie. Folosim această opțiune pentru a evita pierderea tranzacțiilor atunci când toate replicile candidate rămân în urmă.
• InstancePollSeconds — frecvența construirii și actualizării topologiei.
• RecoveryPollSeconds — frecvența analizei topologiei. Dacă este detectată o problemă, este inițiată recuperarea topologiei. Acest constant, egal cu 1 secundă.

Fiecare nod de cluster este interogat de către orchestrator o dată la fiecare InstancePollSeconds secunde Când este detectată o problemă, starea clusterului este forțată actualizat, iar apoi se ia decizia finală de a efectua recuperarea. Experimentând cu diferiți parametri de bază de date și orchestrator, am reușit să reducem timpul de răspuns și de recuperare la 30 de secunde.

stand de testare

Am început să testăm schema HA cu dezvoltarea unui local banc de testare și implementare ulterioară în medii de testare și producție. Standul local este complet automatizat pe baza Docker și vă permite să experimentați cu configurația orchestratorului și a rețelei, să scalați clusterul de la 2-3 servere la câteva zeci și să efectuați exerciții într-un mediu sigur.

În timpul exercițiilor, alegem una dintre metodele de emulare a problemei: împușcă instantaneu maestrul folosind kill -9, terminați ușor procesul și opriți serverul (docker-compose stop), simulează probleme de rețea folosind iptables -j REJECT sau iptables -j DROP. Ne așteptăm la următoarele rezultate:

• orchestratorul va detecta problemele cu masterul și va actualiza topologia în cel mult 10 secunde;
• procedura de recuperare va începe automat: configurația rețelei se va schimba, rolul masterului va trece la replică, topologia va fi reconstruită;
• noul master va deveni inscriptibil, replicile live nu se vor pierde în timpul procesului de reconstrucție;
• datele vor începe să fie scrise în noul master și replicate;
• Timpul total de recuperare nu va depăși 30 de secunde.

După cum știți, sistemul se poate comporta diferit în mediile de testare și producție din cauza diferitelor configurații hardware și de rețea, diferențe de încărcare sintetică și reală etc. Prin urmare, efectuăm periodic exerciții în condiții reale, verificând cum se comportă sistemul atunci când conexiunea la rețea este pierdută sau părțile sale individuale sunt degradate. În viitor, dorim să construim o infrastructură complet identică pentru ambele medii și să automatizăm testarea acesteia.

Constatări

Sănătatea nodului principal al sistemului de stocare este una dintre sarcinile principale ale SRE și ale echipei de operațiuni. Implementarea soluției orchestrator și HA bazată pe VIP ne-a permis să obținem următoarele rezultate:

• detectarea fiabilă a problemelor cu topologia clusterului de baze de date;
• răspuns automat și rapid la incidentele legate de master, reducând timpul de nefuncționare a sistemului.

Cu toate acestea, soluția are limitări și dezavantaje:

• scalarea schemei HA la mai multe centre de date va necesita o singură rețea L2 între ele;
• Înainte de a atribui VIP pe noul master, trebuie să-l lansăm pe cel vechi. Procesul este secvenţial, ceea ce măreşte timpul de recuperare;
• eliberarea VIP-ului necesită acces SSH la server sau orice altă metodă de apelare a procedurilor de la distanță. Deoarece serverul sau baza de date se confruntă cu probleme care au cauzat procesul de recuperare, nu putem fi siguri că eliminarea VIP se va finaliza cu succes. Și acest lucru poate duce la apariția a două servere cu aceeași adresă IP virtuală și o problemă split brain.

A evita split brain, puteți folosi metoda STONITH („Shoot The Other Node In The Head”), care izolează sau dezactivează complet nodul cu probleme. Există și alte modalități de a implementa înaltă disponibilitate a clusterului: o combinație de VIP și DNS, servicii de descoperire a serviciilor și proxy, replicare sincronă și alte metode care au propriile dezavantaje și avantaje.

Am vorbit despre abordarea noastră de a crea un cluster de failover MySQL. Este ușor de implementat și oferă un nivel acceptabil de fiabilitate în condițiile actuale. Pe măsură ce întregul sistem în general și infrastructura în special se dezvoltă, această abordare va evolua fără îndoială.

Sursa: www.habr.com