Citymobil-en MySQL datu-base bat erabiltzen dugu gure datu iraunkorren biltegiratze nagusi gisa. Hainbat datu-base kluster ditugu hainbat zerbitzu eta helburuetarako.

Maisuaren etengabeko erabilgarritasuna sistema osoaren eta banakako zatien errendimenduaren adierazle kritikoa da. Klusterren berreskuratze automatikoak hutsegite nagusi bat gertatuz gero, gertakarien erantzun-denbora eta sistemaren geldialdi-denbora asko murrizten ditu. Artikulu honetan, MySQL kluster baten erabilgarritasun handiko (HA) diseinua aztertuko dut MySQL Orkestratzailea eta IP helbide birtualak (VIP).

VIPn oinarritutako HA irtenbidea

Lehenik eta behin, laburki esango dizut zein den gure datuak biltegiratzeko sistema.

Erreplikazio-eskema klasiko bat erabiltzen dugu idazteko erabilgarri dagoen maisu batekin eta irakurtzeko soilik den erreplika anitzekin. Kluster batek tarteko maisu bat izan dezake, beste batzuentzat erreplika eta maisua den nodo bat. Bezeroek HAProxy-ren bidez atzitzen dituzte erreplikak, eta horrek kargak banatzeko eta erraz eskalatzeko aukera ematen du. HAProxy erabiltzea arrazoi historikoengatik da, eta une honetan ProxySQL-ra migratzeko prozesuan gaude.

Erreplikatzea modu erdi-sinkronoan egiten da oinarrituta GTID. Horrek esan nahi du gutxienez erreplika batek transakzio bat erregistratu behar duela arrakastatzat hartu aurretik. Erreplikazio-modu honek errendimenduaren eta datuen segurtasunaren arteko oreka optimoa eskaintzen du, nodo nagusiaren hutsegiteen kasuan. Funtsean, aldaketa guztiak maisutik errepliketara transferitzen dira Row Based Replication (RBR), baina nodo batzuek izan dezakete mixed binlog format.

Orkestratzaileak aldiro kluster topologiaren egoera eguneratzen du, jasotako informazioa aztertzen du eta arazoak sortzen badira, berreskuratze prozedura automatiko bat abiarazi dezake. Garatzailea da prozedura beraren arduraduna, modu ezberdinetan inplementatu baitaiteke: VIP, DNSn oinarrituta, zerbitzuak aurkitzeko zerbitzuak edo norberak idatzitako mekanismoak erabiliz.

Huts egiten badu maisu bat leheneratzeko modu erraz bat VIP helbide mugikorrak erabiltzea da.

Aurrera egin aurretik irtenbide honi buruz jakin behar duzuna:

• VIP bat sare fisikoko interfaze zehatz batekin lotuta ez dagoen IP helbidea da. Nodo batek huts egiten badu edo programatutako mantentze-lanetan, VIP-a beste baliabide batera alda dezakegu geldialdi gutxirekin.
• IP helbide birtuala askatzea eta ematea eragiketa merkea eta azkarra da.
• VIP-ekin lan egiteko, zerbitzarirako sarbidea behar duzu SSH bidez, edo utilitate berezien erabilera, adibidez, keepalived.

Ikus ditzagun gure morroiaren arazo posibleak eta imajina ditzagun nola funtzionatu behar duen berreskuratze automatikoaren mekanismoak.

Maisuarekiko sare-konexioa desagertu egin da, edo arazo bat sortu da hardware mailan, eta zerbitzaria ez dago erabilgarri

1. Orkestratzaileak kluster topologia eguneratzen du, erreplika bakoitzak maisua erabilgarri ez dagoela jakinarazi du. Orkestratzaileak maisu berriaren eginkizunerako egokia den erreplika hautatzeko prozesua hasten du eta berreskuratzen hasten da.
2. VIP-a maisu zaharretik kentzen saiatzen ari gara - arrakastarik gabe.
3. Erreplika maisu rolera aldatzen da. Topologia berreraikitzen ari da.
4. VIP sareko interfaze berri bat gehitzea. VIP-a kendu ezinezkoa izan denez, aldizka eskaera bat bidaltzen hasten gara atzeko planoan doako ARP. Eskaera/erantzun mota honek IP eta MAC helbideen mapa-taula eguneratzeko aukera ematen du konektatutako etengailuetan, eta, horrela, gure VIP-a mugitu dela jakinaraziko dizu. Horrek probabilitatea murrizten du split brain maisu zaharra itzultzean.
5. Konexio berri guztiak berehala birbideratzen dira maisu berrira. Konexio zaharrek huts egiten dute eta datu-baserako deiak errepikatzen dira aplikazio mailan.

Zerbitzaria modu normalean dabil, hutsegite bat gertatu da DBMS mailan

Algoritmoa aurreko kasuaren antzekoa da: topologia eguneratzea eta berreskuratze prozesua abiaraztea. Zerbitzaria eskuragarri dagoenez, VIP-a arrakastaz askatzen dugu maisu zaharrean, berrira transferitzen dugu eta ARP eskaera hainbat bidaltzen ditugu. Maisu zaharraren itzulera posibleak ez luke berreraikitako klusterrean eta aplikazioaren funtzionamenduan eragin behar.

Beste arazo batzuk

Errepliken edo bitarteko maisuen porrota ez du eramaten ekintza automatikoetara eta eskuzko esku-hartzea eskatzen du.

Sare birtualaren interfazea aldi baterako gehitzen da beti, hau da, zerbitzari bat berrabiarazi ondoren, VIP-a ez da automatikoki esleitzen. Datu-basearen instantzia bakoitza irakurtzeko soilik moduan hasten da lehenespenez, orkestratzaileak automatikoki maisu berria idazteko aldatzen du eta instalatzen saiatzen da. read only maisu zaharraren gainean. Ekintza hauek probabilitatea murriztea dute helburu split brain.

Arazoak sor daitezke berreskuratze-prozesuan, orkestratzailearen interfazearen bidez ere jakinarazi beharko liratekeela monitorizazio-tresna estandarrez gain. REST APIa zabaldu dugu eginbide hau gehituz (PR gaur egun aztertzen ari dira).

Jarraian HA soluzioaren diagrama orokorra aurkezten da.

Maisu berri bat aukeratzea

Orkestratzailea nahikoa inteligentea da eta aukeratzen saiatzen da erreplika egokiena maisu berri gisa, irizpide hauen arabera:

• erreplika maisuaren atzetik geratzen da;
• maisuaren eta erreplikaren MySQL bertsioa;
• erreplikazio mota (RBR, SBR edo mistoa);
• kokapena datu-zentro berean edo desberdinetan;
• erabilgarritasuna errant GTID — erreplikan exekutatu ziren eta maisuan ez dauden transakzioak;
• aukeraketa arau pertsonalizatuak ere kontuan hartzen dira.

Seinale guztiak ez dira maisu izateko hautagai aproposa. Adibidez, erreplika bat erabil daiteke datuen babeskopia egiteko, edo zerbitzariak hardware konfigurazio ahulagoa du. Orkestratzailea euskarriak eskuliburuko arauak zeintzuekin zure hautagaien hautapen-hobespenak pertsonaliza ditzakezu hobetsienetatik baztertu izatera.

Erantzun eta berreskuratzeko denbora

Gorabehera bat gertatuz gero, garrantzitsua da sistemaren geldialdi-denbora gutxitzea, beraz, kontuan ditzagun orkestratzaileak cluster topologiaren sorreran eta eguneratzean eragiten duten MySQL parametroak:

• slave_net_timeout — Erreplikak maisuaren datu berriak edo taupadaren seinalea iristeko itxaron behar duen segundo kopurua, konexioa galdu eta berriro konektatu arte. Zenbat eta balioa txikiagoa izan, orduan eta azkarrago zehaztu ahal izango du erreplikak maisuarekiko komunikazioa hautsita dagoela. Balio hau 5 segundotan ezarri dugu.
• MASTER_CONNECT_RETRY — Berriro konektatzeko saiakeraren arteko segundo kopurua. Sareko arazoak izanez gero, parametro honen balio baxuak berriro konektatzeko aukera emango du eta kluster berreskuratzeko prozesua abiatzea eragotziko du. Gomendatutako balioa segundo 1 da.
• MASTER_RETRY_COUNT — birkonexio-saiakeraren gehienezko kopurua.
• MASTER_HEARTBEAT_PERIOD — segundotan tartea, eta ondoren maisuak bihotz-taupadaren seinalea bidaltzen du. Balioaren erdia lehenetsita dago slave_net_timeout.

Orkestratzailearen aukerak:

• DelayMasterPromotionIfSQLThreadNotUpToDate - berdina bada true, orduan rol maisua ez da hautagaiaren erreplikan aplikatuko erreplikaren SQL hariak Erreleboko erregistrotik aplikatu gabeko transakzio guztiak osatu arte. Aukera hau erabiltzen dugu transakzioak galtzea saihesteko, hautagaien erreplika guztiak atzean geratzen direnean.
• InstancePollSeconds — Topologia eraikitzeko eta eguneratzeko maiztasuna.
• RecoveryPollSeconds — Topologia-analisiaren maiztasuna. Arazoren bat hautematen bada, topologia berreskuratzen hasiko da. Hau konstantea, segundo 1 berdina.

Cluster-nodo bakoitza behin behin galdetzen du orkestratzaileak InstancePollSeconds segundoak Arazo bat detektatzen denean, kluster egoera behartu egiten da eguneratua, eta, ondoren, berreskurapena egiteko azken erabakia hartzen da. Datu-base eta orkestratzaile parametro ezberdinekin esperimentatuz, erantzuna eta berreskuratze denbora 30 segundora murriztea lortu genuen.

proba-bankua

HA eskema probatzen hasi ginen lokal baten garapenarekin proba-bankua eta gehiago inplementatzea proba eta ekoizpen inguruneetan. Tokiko standa guztiz automatizatuta dago Docker-en oinarrituta eta aukera ematen du orkestratzailearen eta sarearen konfigurazioarekin esperimentatzeko, klusterra 2-3 zerbitzarietatik dozena batzuetara eskalatzeko eta ariketak ingurune seguru batean egiteko.

Ariketetan zehar, arazoen emulazio metodoetako bat aukeratzen dugu: berehala tiro egin maisua erabiliz kill -9, amaitu leunki prozesua eta gelditu zerbitzaria (docker-compose stop), sareko arazoak erabiliz simulatu iptables -j REJECT edo iptables -j DROP. Emaitza hauek espero ditugu:

• orkestratzaileak maisuarekin arazoak detektatuko ditu eta topologia eguneratuko du 10 segundo baino gehiagotan;
• berreskuratzeko prozedura automatikoki hasiko da: sarearen konfigurazioa aldatuko da, maisuaren rola erreplikara pasatuko da, topologia berreraiki egingo da;
• maisu berria idazteko modukoa izango da, zuzeneko erreplikak ez dira galduko berreraikitze prozesuan;
• datuak maisu berrian idazten eta errepikatzen hasiko dira;
• Berreskuratzeko denbora osoa ez da 30 segundo baino gehiagokoa izango.

Dakizuenez, sistemak proba- eta ekoizpen-inguruneetan ezberdin joka dezake hardware- eta sare-konfigurazio desberdinengatik, karga sintetiko eta errealeko desberdintasunak, etab. Hori dela eta, aldian-aldian ariketak egiten ditugu baldintza errealetan, sare-konektibitatea galtzen denean edo bere zati indibidualak hondatzen direnean sistemak nola jokatzen duen egiaztatuz. Etorkizunean, bi inguruneetarako azpiegitura guztiz berdina eraiki eta haren probak automatizatu nahi ditugu.

Findings

Biltegiratze-sistemaren nodo nagusiaren osasuna SRE eta operazio taldearen zeregin nagusietako bat da. VIPn oinarritutako orkestratzailea eta HA irtenbidearen ezarpenak emaitza hauek lortu ahal izan zituen:

• datu-basearen klusterraren topologiaren arazoen detekzio fidagarria;
• maisuari lotutako gertakariei erantzun automatikoa eta azkarra, sistemaren geldialdi-denbora murriztuz.

Hala ere, irtenbideak bere mugak eta desabantailak ditu:

• HA eskema hainbat datu-zentrotara eskalatzeak haien artean L2 sare bakarra beharko du;
• Master berrian VIP esleitu aurretik, zaharrean askatu behar dugu. Prozesua sekuentziala da, eta horrek berreskuratzeko denbora handitzen du;
• VIP-a askatzeak zerbitzarirako SSH sarbidea behar du, edo urruneko prozedurak deitzeko beste edozein metodo. Zerbitzariak edo datu-baseak berreskuratze-prozesua eragin duten arazoak izaten ari direnez, ezin dugu ziurtatu VIP kentzea arrakastaz amaituko denik. Eta honek IP helbide birtual bera duten bi zerbitzari ager daitezke eta arazo bat split brain.

Saihestu split brain, metodoa erabil dezakezu STONITH ("Shoot The Other Node In The Head"), arazoaren nodoa erabat isolatzen edo desgaitzen duena. Klusterren erabilgarritasun handia ezartzeko beste modu batzuk daude: VIP eta DNS konbinazioa, zerbitzuen aurkikuntza eta proxy zerbitzuak, erreplikazio sinkronikoa eta beren desabantailak eta abantailak dituzten beste metodo batzuk.

MySQL failover kluster bat sortzeko gure ikuspegiari buruz hitz egin nuen. Erraza da inplementatzen eta fidagarritasun maila onargarria eskaintzen du egungo baldintzetan. Sistema osoa, oro har, eta bereziki azpiegiturak garatzen diren heinean, ikuspegi honek bilakaera izango du, dudarik gabe.

Iturria: www.habr.com