Enige groot projek het begin met 'n paar bedieners. Eers was daar een DB-bediener, toe is slawe daarby gevoeg om die lesing te skaal. En dan - stop! Daar is een heer, maar daar is baie slawe; as een van die slawe vertrek, dan sal alles reg wees, maar as die meester vertrek, sal dit sleg wees: stilstand, admins probeer die bediener verhoog. Wat om te doen? Bespreek 'n meester. My kollega Pavel het reeds hieroor geskryf , Ek sal dit nie herhaal nie. In plaas daarvan sal ek jou vertel hoekom jy beslis Orchestrator vir MySQL nodig het!
Kom ons begin met die hoofvraag: "Hoe sal ons die kode na 'n nuwe masjien oorskakel wanneer die meester vertrek?"
- Ek hou die meeste van die skema met VIP (Virtual IP), ons sal hieronder daaroor praat. Dit is die eenvoudigste en mees voor die hand liggend, hoewel dit 'n ooglopende beperking het: die meester wat ons sal reserveer, moet in die L2-segment wees met die nuwe masjien, dit wil sê, ons kan van die tweede DC vergeet. En, op 'n vriendskaplike manier, as jy die reël volg dat 'n groot L2 boos is, want L2 is net per rek, en L3 is tussen die rakke, en so 'n skema het selfs meer beperkings.
- Jy kan 'n DNS-naam in die kode skryf en dit oplos deur /etc/hosts. Trouens, daar sal geen oplossing wees nie. Die voordeel van die skema: daar is geen beperking kenmerk van die eerste metode nie, dit wil sê, dit is moontlik om 'n kruis-DC te organiseer. Maar dan ontstaan die ooglopende vraag: hoe vinnig kan ons die verandering aan /etc/hosts via Puppet-Ansible lewer?
- U kan die tweede metode 'n bietjie verander: installeer kas-DNS op alle webbedieners, waardeur die kode na die hoofdatabasis sal gaan. U kan TTL 60 vir hierdie inskrywing in DNS stel. Dit blyk dat die metode goed is as dit korrek geïmplementeer word.
- 'n Skema met diensontdekking, wat die gebruik van Consul en ens impliseer.
- N interessante opsie met . Jy moet alle verkeer na MySQL deur ProxySQL stuur; ProxySQL self kan bepaal wie die meester is. Terloops, jy kan lees oor een van die opsies vir die gebruik van hierdie produk in my .
Die skrywer van Orchestrator, wat in Github werk, het eers die eerste skema met VIP geïmplementeer, en dit toe omgeskakel na 'n skema met konsul.
Tipiese infrastruktuuruitleg:
Ek sal dadelik die ooglopende situasies beskryf wat in ag geneem moet word:
- Die VIP-adres moet nie in die konfigurasie op enige van die bedieners geregistreer wees nie. Kom ons stel ons 'n situasie voor: die meester het herlaai, en terwyl dit laai, het Orchestrator in failover-modus gegaan en een van die slawe 'n meester gemaak; toe staan die ou meester op, en nou is die VIP op twee karre. Dit is sleg.
- Vir die orkeseerder sal jy 'n draaiboek moet skryf om die ou meester en die nuwe meester te noem. Op die ou meester moet jy ifdown hardloop, en op die nuwe meester - ifup vip. Dit sal lekker wees om ook in hierdie skrif in te sluit dat in die geval van 'n failover, die poort op die ou meester se skakelaar eenvoudig afgeskakel word om enige splitbrein te vermy.
- Nadat Orchestrator jou skrif geroep het om eers die VIP te verwyder en/of die poort op die skakelaar te blus, en dan die VIP-verhogingskrip op die nuwe meester geroep het, moenie vergeet om die arping-opdrag te gebruik om almal te vertel dat die nuwe VIP nou is nie hier.
- Alle slawe moes read_only=1 gehad het, en sodra jy die slaaf tot die meester bevorder, moes dit read_only=0 gehad het.
- Moenie vergeet dat enige slaaf wat ons hiervoor gekies het 'n meester kan word nie (Orkestreerder het 'n hele voorkeurmeganisme vir watter slaaf om te oorweeg as 'n kandidaat vir 'n nuwe meester in die eerste plek, watter in die tweede plek, en watter slaaf moet glad nie onder enige omstandighede meester gekies word nie). As die slaaf 'n meester word, dan sal die las van die slaaf daarop bly en die las van die meester sal bygevoeg word, dit moet in ag geneem word.
Hoekom het jy Orchestrator nodig as jy nie een het nie?
- Orchestrator het 'n baie gebruikersvriendelike grafiese koppelvlak wat die hele topologie vertoon (sien skermkiekie hieronder).
- Orchestrator kan opspoor watter slawe agterbly en waar replikasie oor die algemeen onklaar geraak het (ons het skrifte wat aan Orchestrator geheg is vir die stuur van SMS).
- Orchestrator vertel jou watter slawe 'n GTID-dwaling het.
Orchestrator Interface:
Wat is GTID dwaal?
Daar is twee hoofvereistes vir Orchestrator om te werk:
- Dit is nodig dat pseudo GTID op alle masjiene in die MySQL-groepering geaktiveer is; ons het GTID geaktiveer.
- Dit is nodig dat daar oral een soort binlogs is, jy kan stelling gebruik. Ons het 'n konfigurasie gehad waarin die meester en die meeste slawe Row gehad het, en twee het histories in die Gemengde modus gebly. As gevolg hiervan wou Orchestrator eenvoudig nie hierdie slawe aan die nuwe meester koppel nie.
Onthou dat die belangrikste ding in 'n produksieslaaf sy konsekwentheid met die meester is! As jy Global Transaction ID (GTID) op beide jou meester en slaaf geaktiveer het, kan jy die gtid_subset-funksie gebruik om uit te vind of dieselfde versoeke vir dataveranderings werklik op hierdie masjiene uitgevoer is. Jy kan meer hieroor lees .
Dus, Orchestrator wys jou deur die GTID dwalende dat daar transaksies op die slaaf is wat nie op die meester is nie. Hoekom gebeur dit?
- Read_only=1 is nie geaktiveer op die slaaf nie, iemand het gekoppel en 'n versoek voltooi om data te verander.
- Super_read_only=1 is nie op die slaaf geaktiveer nie, toe het die admin, wat die bediener verwar het, ingegaan en die versoek daar uitgevoer.
- As jy albei vorige punte in ag geneem het, dan is daar nog een truuk: in MySQL gaan 'n versoek om binlogs te spoel ook na die binlog, so by die eerste spoel sal 'n GTID-dwaling op die meester en alle slawe verskyn. Hoe om dit te vermy? Perona-5.7.25-28 het die binlog_skip_flush_commands=1-instelling bekendgestel, wat die skryf van spoel na binlogs verbied. Daar is 'n gevestigde een op die mysql.com webwerf .
Laat ek al die bogenoemde opsom. As jy nog nie Orchestrator in failover-modus wil gebruik nie, plaas dit dan in waarnemingsmodus. Dan sal jy altyd 'n kaart voor jou oë hê van die interaksie van MySQL-masjiene en visuele inligting oor watter tipe replikasie op elke masjien is, of die slawe agterbly, en die belangrikste, hoe konsekwent hulle met die meester is!
Die ooglopende vraag is: "Hoe moet Orchestrator werk?" Hy moet 'n nuwe meester uit die huidige slawe kies, en dan alle slawe weer daaraan koppel (dit is waarvoor GTID nodig is; as jy die ou meganisme met binlog_name en binlog_pos gebruik, skakel dan 'n slaaf van die huidige meester na 'n nuwe een oor is eenvoudig onmoontlik!). Voordat ons Orchestrator gehad het, moes ek dit alles met die hand doen. Die ou meester het gehang weens 'n karretjie Adaptec-beheerder; dit het ongeveer 10 slawe gehad. Ek moes VIP van die meester na een van die slawe oorplaas en alle ander slawe weer daaraan koppel. Hoeveel konsoles moes ek oopmaak, hoeveel gelyktydige opdragte het ek ingevoer... Ek moes wag tot 3:XNUMX, verwyder die las van alle slawe behalwe twee, maak die eerste masjien uit twee meester, heg dadelik die tweede masjien aan daaraan, heg dus al die ander slawe aan die nuwe meester en gee die vrag terug. In die algemeen, verskriklik ...
Hoe werk Orchestrator wanneer dit in failover-modus gaan? Dit word die maklikste geïllustreer deur 'n voorbeeld van 'n situasie waar ons 'n meester 'n kragtiger, meer moderne masjien wil maak as wat ons nou het.
Die figuur toon die middel van die proses. Wat is reeds tot op hierdie stadium gedoen? Ons het gesê dat ons een of ander slaaf die nuwe meester wil maak, Orchestrator het eenvoudig alle ander slawe daaraan begin koppel, met die nuwe meester wat as 'n transitomasjien opgetree het. Met hierdie skema kom geen foute voor nie, alle slawe werk, Orchestrator verwyder die VIP van die ou meester, dra dit oor na die nuwe een, maak read_only=0 en vergeet van die ou meester. Almal! Die stilstand van ons diens is die VIP-oordragtyd, wat 2-3 sekondes is.
Dis al vir vandag, dankie almal. Daar sal binnekort 'n tweede artikel oor Orchestrator wees. In die beroemde Sowjet-film "Garage" het een karakter gesê: "Ek sal nie saam met hom op verkenning gaan nie!" So, orkesmeester, ek sal saam met jou op verkenning gaan!
Bron: will.com