By Citymobil brûke wy in MySQL-database as ús wichtichste persistente gegevensopslach. Wy hawwe ferskate databankklusters foar ferskate tsjinsten en doelen.
De konstante beskikberens fan 'e master is in krityske yndikator fan' e prestaasjes fan it heule systeem en har yndividuele dielen. Automatysk klusterherstel yn it gefal fan in masterfout ferminderet de reaksjetiid fan ynsidint en systeemdowntime sterk. Yn dit artikel sil ik sjen nei in ûntwerp mei hege beskikberens (HA) foar in MySQL-kluster basearre op en firtuele IP-adressen (VIP).
HA oplossing basearre op VIP
Earst sil ik jo koart fertelle wat ús gegevensopslachsysteem is.
Wy brûke in klassyk replikaasjeskema mei ien skriuwberikbere master en meardere read-allinnich replika's. In kluster kin in tuskenlizzende master befetsje - in knooppunt dat sawol in replika as in master is foar oaren. Klanten krije tagong ta replika's fia HAProxy, wêrtroch't sels loadferdieling en maklike skaalfergrutting mooglik is. It gebrûk fan HAProxy komt troch histoaryske redenen, en wy binne op it stuit yn it proses fan migraasje nei ProxySQL.
Replikaasje wurdt útfierd yn semy-syngroane modus basearre op GTID. Dit betsjut dat op syn minst ien replika in transaksje oanmelde moat foardat it as suksesfol beskôge wurdt. Dizze replikaasjemodus soarget foar in optimaal lykwicht tusken prestaasjes en gegevensfeiligens yn gefal fan in masterknooppuntfal. Yn prinsipe wurde alle wizigingen oerdroegen fan 'e master nei de replika's mei help fan Row Based Replication (RBR), mar guon knopen kinne hawwe mixed binlog format.
De orkestrator fernijt periodyk de steat fan 'e klustertopology, analysearret de ûntfongen ynformaasje, en as problemen ûntsteane, kin it in automatyske herstelproseduere starte. De ûntwikkelder is ferantwurdlik foar de proseduere sels, om't it op ferskate manieren kin wurde útfierd: basearre op VIP, DNS, mei help fan tsjinsten foar ûntdekking fan tsjinsten of selsskreaune meganismen.
Ien ienfâldige manier om in master te herstellen as it mislearret is driuwende VIP-adressen te brûken.
Wat jo witte moatte oer dizze oplossing foardat jo foarút gean:
- In VIP is in IP-adres dat net ferbûn is mei in spesifike fysike netwurkynterface. As in knooppunt mislearret of ûnder pland ûnderhâld, kinne wy de VIP oerskeakelje nei in oare boarne mei minimale downtime.
- It befrijen en útjaan fan in firtuele IP-adres is in goedkeap en rappe operaasje.
- Om mei VIP te wurkjen, moatte jo tagong hawwe ta de tsjinner fia SSH, of it brûken fan spesjale nutsbedriuwen, bygelyks,
keepalived.
Litte wy nei mooglike problemen mei ús wizard sjen en yntinke hoe't it automatysk herstelmeganisme moat wurkje.
Netwurkferbining mei de master is ferdwûn, of der is in probleem ûntstien op hardwarenivo, en de tsjinner is net beskikber
- De orkestrator fernijt de klustertopology, elke replika meldt dat de master net beskikber is. De orkestrator begjint it proses fan it selektearjen fan in replika geskikt foar de rol fan 'e nije master en begjint herstel.
- Wy besykje de VIP fan 'e âlde master te ferwiderjen - sûnder sukses.
- De replika skeakelt oer nei de rol fan master. De topology wurdt werboud.
- It tafoegjen fan in nije netwurkynterface mei VIP. Om't it net mooglik wie om de VIP te ferwiderjen, begjinne wy periodyk in fersyk op 'e eftergrûn te ferstjoeren fergees ARP. Dit soarte fan fersyk / antwurd lit jo de IP- en MAC-adresmappingtabel bywurkje op 'e ferbûne skeakels, en jo dêrmei ynformearje dat ús VIP is ferpleatst. Dit minimalisearret de kâns
split brainby it werombringen fan de âlde master. - Alle nije ferbinings wurde fuortendaliks trochstjoerd nei de nije master. Alde ferbiningen mislearje en werhelle oproppen nei de databank wurde makke op it tapassingsnivo.
De tsjinner wurket yn normale modus, der barde in flater op it DBMS-nivo
It algoritme is fergelykber mei it foarige gefal: it bywurkjen fan de topology en it begjinnen fan it herstelproses. Sûnt de tsjinner is beskikber, wy mei súkses loslitte de VIP op 'e âlde master, oerdrage it nei de nije, en stjoere ferskate ARP fersiken. De mooglike weromreis fan 'e âlde master soe gjin ynfloed hawwe op it opnij opboude kluster en de wurking fan' e applikaasje.
Oare problemen
Mislearring fan replika's of tuskenmasters net liede oan automatyske aksjes en fereasket hânmjittich yntervinsje.
In firtuele netwurkynterface wurdt altyd tydlik tafoege, dat is, nei in tsjinner opnij opstart, wurdt de VIP net automatysk tawiisd. Elke database-eksimplaar begjint standert yn allinich-lêsmodus, de orkestrator skeakelt automatysk de nije master om te skriuwen en besiket te ynstallearjen read only op de âlde master. Dizze aksjes binne rjochte op it ferminderjen fan de kâns split brain.
Problemen kinne ûntstean tidens it herstelproses, dat ek moatte wurde op 'e hichte brocht fia de orkestrator UI neist standert monitoring-ark. Wy hawwe de REST API útwreide troch dizze funksje ta te foegjen ( op it stuit ûnder beoardieling).
It algemiene diagram fan 'e HA-oplossing wurdt hjirûnder presintearre.
Kieze in nije master
De orkestrator is tûk genôch en besiket te kiezen as nije master neffens de folgjende kritearia:
- de replika bliuwt efter de master;
- MySQL ferzje fan master en replika;
- replikaasjetype (RBR, SBR of mingd);
- lokaasje yn deselde of ferskillende datasintra;
- beskikberens
errant GTID- transaksjes dy't waarden útfierd op 'e replika en binne net op' e master; - oanpaste seleksje regels wurde ek rekken holden.
Net elke cue is in ideale kandidaat foar in master. Bygelyks, in replika kin brûkt wurde foar reservekopy gegevens, of de tsjinner hat in swakkere hardware konfiguraasje. Orkestrator hânmjittich regels wêrmei jo kinne oanpasse jo kandidaat seleksje foarkar fan meast foarkar oan negearre.
Response en hersteltiid
Yn it gefal fan in ynsidint is it wichtich om systeemdowntime te minimalisearjen, dus litte wy de MySQL-parameters beskôgje dy't ynfloed hawwe op it meitsjen en bywurkjen fan 'e klustertopology troch de orkestrator:
- - it oantal sekonden wêryn't de replika wachtet op nije gegevens as in hertslachsinjaal om fan 'e master te kommen foardat de ferbining wurdt erkend as ferlern en opnij ferbûn. Hoe leger de wearde, hoe flugger de replika kin bepale dat kommunikaasje mei de master is brutsen. Wy sette dizze wearde op 5 sekonden.
- - oantal sekonden tusken opnij ferbining besykjen. Yn it gefal fan netwurkproblemen sil in lege wearde foar dizze parameter rappe opnij ferbining meitsje en foarkomme dat it klusterherstelproses begjint. De rekommandearre wearde is 1 sekonde.
MASTER_RETRY_COUNT- maksimum oantal reconnection besykjen.MASTER_HEARTBEAT_PERIOD- ynterval yn sekonden wêrnei't de master in hertslachsinjaal stjoert. Standert op de helte fan de weardeslave_net_timeout.
Orchestrator parameters:
DelayMasterPromotionIfSQLThreadNotUpToDate- as gelyktrue, dan sil de masterrol net tapast wurde op 'e kandidaat-replika oant de SQL-thread fan 'e replika alle net tapaste transaksjes fan it Relay-log hat foltôge. Wy brûke dizze opsje om foar te kommen ferliezen transaksjes doe't alle kandidaat replika falle efter.InstancePollSeconds- frekwinsje fan it bouwen en bywurkjen fan de topology.RecoveryPollSeconds- frekwinsje fan topology analyze. As in probleem wurdt ûntdutsen, wurdt topology herstel inisjearre. Dit, lyk oan 1 sekonde.
Elk klusterknooppunt wurdt ien kear troch de orkestrator ûndersocht InstancePollSeconds sekonden As in probleem wurdt ûntdutsen, wurdt de klusterstatus twongen, en dan wurdt it definitive beslút makke om herstel út te fieren. Troch te eksperimintearjen mei ferskate databank- en orkestratorparameters, koene wy de reaksje- en hersteltiid ferminderje nei 30 sekonden.
test stand
Wy begûnen it HA-skema te testen mei de ûntwikkeling fan in lokale en fierdere ymplemintaasje yn test- en produksjeomjouwings. De lokale stand is folslein automatisearre basearre op Docker en lit jo eksperimintearje mei de konfiguraasje fan 'e orkestrator en netwurk, skaal it kluster fan 2-3 servers nei ferskate tsientallen, en útfiere oefeningen yn in feilige omjouwing.
Tidens de oefeningen kieze wy ien fan 'e probleememulaasjemetoaden: sjit de master direkt mei kill -9, beëinigje it proses sêft en stopje de tsjinner (docker-compose stop), simulearje netwurkproblemen mei help fan iptables -j REJECT of iptables -j DROP. Wy ferwachtsje de folgjende resultaten:
- de orkestrator sil problemen mei de master ûntdekke en de topology yn net mear as 10 sekonden bywurkje;
- de herstelproseduere sil automatysk begjinne: de netwurkkonfiguraasje sil feroarje, de rol fan 'e master sil trochjaan oan' e replika, de topology wurdt werboud;
- de nije master sil skriuwber wurde, live replika's sille net ferlern gean tidens it werbouproses;
- gegevens sille begjinne te wurden skreaun nei de nije master en replicated;
- De totale hersteltiid sil net mear wêze as 30 sekonden.
Lykas jo witte, kin it systeem oars gedrage yn test- en produksjeomjouwings fanwege ferskillende hardware- en netwurkkonfiguraasjes, ferskillen yn syntetyske en echte lading, ensfh. Dêrom fiere wy periodyk oefeningen yn echte omstannichheden, kontrolearjen hoe't it systeem gedraacht as netwurkferbining ferlern giet of syn yndividuele dielen wurde degradearre. Yn 'e takomst wolle wy in folslein identike ynfrastruktuer bouwe foar beide omjouwings en har testen automatisearje.
befinings
De sûnens fan it knooppunt fan it haad opslachsysteem is ien fan 'e haaddoelen fan it SRE- en operaasjeteam. De ymplemintaasje fan 'e orkestrator en HA-oplossing basearre op VIP liet ús de folgjende resultaten berikke:
- betroubere deteksje fan problemen mei de topology fan it databankkluster;
- automatyske en rappe reaksje op master-relatearre ynsidinten, ferminderjen systeem downtime.
De oplossing hat lykwols syn beheiningen en neidielen:
- it skaaljen fan it HA-skema nei ferskate datasintra sil in inkeld L2-netwurk tusken har fereaskje;
- Foardat jo VIP op 'e nije master tawize, moatte wy it op' e âlde loslitte. It proses is sekwinsjele, wat fergruttet de hersteltiid;
- it frijjaan fan de VIP fereasket SSH-tagong ta de tsjinner, as in oare metoade om prosedueres op ôfstân te skiljen. Sûnt de tsjinner of databank ûnderfynt problemen dy't feroarsake it herstel proses, wy kinne net der wis fan wêze dat de VIP ferwidering sil foltôge mei súkses. En dit kin liede ta it ferskinen fan twa servers mei itselde firtuele IP-adres en in probleem
split brain.
Om foar te kommen split brain, kinne jo gebrûk meitsje fan de metoade ("Sjit The Other Node In The Head"), dy't it probleemknooppunt folslein isolearret of útskeakelje. D'r binne oare manieren om kluster hege beskikberens út te fieren: in kombinaasje fan VIP en DNS, tsjinst ûntdekking en proxy tsjinsten, syngroane replikaasje en oare metoaden dy't har eigen neidielen en foardielen hawwe.
Ik spruts oer ús oanpak foar it meitsjen fan in MySQL failover-kluster. It is maklik te ymplementearjen en biedt in akseptabel nivo fan betrouberens ûnder hjoeddeistige omstannichheden. As it hiele systeem yn it algemien en ynfrastruktuer yn it bysûnder ûntwikkelje, sil dizze oanpak sûnder mis evoluearje.
Boarne: www.habr.com