Iga suur projekt sai alguse paarist serverist. Alguses oli üks DB-server, siis lisati sellele orjad, et näitu skaleerida. Ja siis - stopp! Isand on üks, aga orje on palju; kui üks orjadest lahkub, siis on kõik hästi, aga kui peremees lahkub, on see halb: seisak, administraatorid üritavad serverit tõsta. Mida teha? Reserveeri meister. Mu kolleeg Pavel kirjutas sellest juba , ma ei korda seda. Selle asemel ütlen teile, miks te kindlasti MySQL-i jaoks Orchestratorit vajate!
Alustame põhiküsimusega: "Kuidas lülitame koodi uuele masinale, kui kapten lahkub?"
- Mulle meeldib kõige rohkem skeem VIPiga (Virtual IP), sellest räägime allpool. See on kõige lihtsam ja ilmsem, kuigi sellel on ilmselge piirang: kapten, kelle me reserveerime, peab olema uue masinaga segmendis L2, see tähendab, et me võime unustada teise alalisvoolu. Ja sõbralikult, kui järgida reeglit, et suur L2 on paha, sest L2 on ainult riiuli kohta ja L3 on riiulite vahel ja sellisel skeemil on veelgi rohkem piiranguid.
- Saate koodi kirjutada DNS-nime ja lahendada selle läbi /etc/hosts. Tegelikult lahendust ei tule. Skeemi eelis: esimesele meetodile iseloomulikud piirangud puuduvad, see tähendab, et on võimalik korraldada rist-DC. Kuid siis tekib ilmne küsimus: kui kiiresti saame muudatuse Puppet-Ansible kaudu faili /etc/hosts toimetada?
- Teist meetodit saate veidi muuta: installige kõigisse veebiserveritesse vahemällu salvestatud DNS, mille kaudu kood läheb põhiandmebaasi. Selle DNS-i kirje jaoks saate määrata TTL 60. Tundub, et õige rakendamise korral on meetod hea.
- Teenuse avastamise skeem, mis viitab konsuli ja jne kasutamisele.
- Huvitav variant koos . Peate kogu liikluse MySQL-i suunama ProxySQL-i kaudu; ProxySQL saab ise määrata, kes on ülem. Muide, ühe selle toote kasutamise võimaluse kohta saate lugeda minu lehelt .
Githubis töötav Orchestratori autor rakendas esimese skeemi esmalt VIP-iga ja seejärel teisendas selle konsuliga skeemiks.
Tüüpiline infrastruktuuri paigutus:
Kirjeldan kohe ilmseid olukordi, mida tuleb arvesse võtta:
- VIP-aadressi ei tohiks ühegi serveri konfiguratsioonis registreerida. Kujutagem ette olukorda: master taaskäivitas ja laadimise ajal läks Orchestrator tõrkevahetusrežiimi ja muutis ühest alluvast peremeheks; siis tõusis vanameister ja nüüd on VIP kahel autol. See on halb.
- Orkestri jaoks peate kirjutama skripti vanale ja uuele meistrile helistamiseks. Vanal masteril tuleb käivitada ifdown ja uuel masteril ifup vip. Oleks tore lisada sellesse skripti ka see, et tõrkevahetuse korral lülitatakse vana põhilüliti port lihtsalt välja, et vältida aju jagamist.
- Kui Orchestrator on kutsunud teie skripti esmalt VIP-i eemaldamiseks ja/või lüliti pordi kustutamiseks ning seejärel uue masteri VIP-i tõstmisskripti kutsunud, ärge unustage kasutada käsku arping, et öelda kõigile, et uus VIP on nüüd siin.
- Kõigil alamseadmetel peaks olema read_only=1 ja niipea, kui alam ülendate, peaks see olema ainult read_only=0.
- Ärge unustage, et igast orjast, kelle oleme selleks valinud, võib saada peremees (orkestril on terve eelistusmehhanism, millist orja uue peremehe kandidaadiks pidada esiteks, millist teiseks ja millist orja peaks ei tohi mingil juhul olla valitud kapten). Kui alam saab peremeheks, siis alluva koormus jääb sellele ja peremehe koormus lisandub, sellega tuleb arvestada.
Miks on teil Orchestratorit vaja, kui teil seda pole?
- Orchestratoril on väga kasutajasõbralik graafiline liides, mis kuvab kogu topoloogia (vt allpool olevat ekraanipilti).
- Orchestrator saab jälgida, millised orjad on maha jäänud ja kus replikatsioon on üldiselt katki läinud (meil on Orchestratorile lisatud skriptid SMS-i saatmiseks).
- Orchestrator ütleb teile, millistel orjadel on GTID viga.
Orkestri liides:
Mis on GTID ekslik?
Orchestratori tööks on kaks peamist nõuet:
- Kõigis MySQL-klastri masinates peab pseudoGTID olema lubatud; meil on GTID lubatud.
- Vaja on, et igal pool oleks üht tüüpi binlogid, saab kasutada lauset. Meil oli konfiguratsioon, milles ülemsel ja enamikul alluvatel oli Row ja kaks jäid ajalooliselt segarežiimile. Selle tulemusena ei tahtnud Orchestrator neid orje lihtsalt uue isandaga ühendada.
Pidage meeles, et tootmise orja juures on kõige olulisem selle järjepidevus peremehega! Kui teil on nii ülem- kui ka alamseadmes lubatud globaalne tehingu ID (GTID), saate funktsiooni gtid_subset abil välja selgitada, kas nendes masinates on tegelikult täidetud samu andmete muutmise taotlusi. Selle kohta saate rohkem lugeda .
Seega näitab Orchestrator teile GTID vea kaudu, et alamseadmes on tehinguid, mida ülemseadmes ei ole. Miks see juhtub?
- Read_only=1 ei ole alamseadmes lubatud, keegi ühendas ja täitis andmete muutmise taotluse.
- Super_read_only=1 ei ole alamseadmel lubatud, siis admin, olles serveri segamini ajanud, läks sisse ja täitis seal päringu.
- Kui arvestada mõlema eelneva punktiga, siis on veel üks nipp: MySQL-is läheb binlogide loputamise taotlus ka binlogi, nii et esimesel loputamisel ilmub ülemale ja kõikidele alamseadmetele GTID errant. Kuidas seda vältida? Perona-5.7.25-28 võttis kasutusele sätte binlog_skip_flush_commands=1, mis keelab binlogidesse masti kirjutamise. Veebisaidil mysql.com on see loodud .
Lubage mul teha kokkuvõte kõigest ülaltoodust. Kui te ei soovi veel Orchestratorit tõrkesiirderežiimis kasutada, siis pange see vaatlusrežiimi. Siis on alati teie silme ees MySQL-i masinate koostoime kaart ja visuaalne teave selle kohta, mis tüüpi replikatsioon igal masinal on, kas orjad on maha jäänud ja mis kõige tähtsam, kui järjekindlad nad on ülemseadmega!
Ilmselge küsimus on: "Kuidas peaks Orchestrator töötama?" Ta peab valima praeguste alamseadmete hulgast uue ülemseadme ja seejärel ühendama sellega uuesti kõik alamseadmed (selleks on vaja GTID-d; kui kasutate vana mehhanismi koos binlog_name ja binlog_pos, siis lülitage alam praeguselt ülemseadmelt uuele on lihtsalt võimatu!). Enne kui meil oli Orchestrator, pidin seda kõike käsitsi tegema. Vanameister rippus lollaka Adapteci kontrolleri tõttu, sellel oli umbes 10 orja. Mul oli vaja VIP-i ülemseadmelt ühele alluvale üle kanda ja kõik teised alamseadmed sellega uuesti ühendada. Mitu konsooli pidin avama, mitu käsku üheaegselt sisestasin... Pidin ootama kella 3-ni öösel, eemaldama koormuse kõigilt orjadelt peale kahe, tegema esimese masina kahest masterist, kohe kinnitama teise masina selle külge, nii et ühendage kõik teised orjad uue peremehe külge ja tagastage koorem. Kokkuvõttes kohutav...
Kuidas Orchestrator töötab, kui see läheb tõrkesiirderežiimi? Seda illustreerib kõige kergemini näide olukorrast, kus tahame teha meistrist võimsama, kaasaegsema masina kui praegu.
Joonisel on kujutatud protsessi keskpaik. Mida on praeguseks juba tehtud? Ütlesime, et tahame mõnest orjast teha uueks peremeheks, Orchestrator hakkas lihtsalt kõik teised orjad sellega uuesti ühendama, uus peremees toimis transiidimasinana. Selle skeemi puhul vigu ei teki, kõik slaved töötavad, Orchestrator eemaldab VIP-i vanast masterist, kannab selle uude, teeb read_only=0 ja unustab vana masteri. Kõik! Meie teenuse seisakuaeg on VIP ülekande aeg, mis on 2-3 sekundit.
See on tänaseks kõik, tänan teid kõiki. Peagi ilmub teine artikkel Orchestratori kohta. Kuulsas Nõukogude filmis "Garaaž" ütles üks tegelane: "Ma ei läheks temaga luurele!" Niisiis, orkestrant, ma läheksin teiega luurele!
Allikas: www.habr.com