Iga suur projekt hakkas paarist serverist. Esiteks oli üks andmebaasi server, seejärel lisati sellele orjad, et lugemist skaala suurendada. Ja siin — stopp! Meistrit on üks, aga orjasid palju; kui üks orjast lahkub, siis kõik on korras, aga kui meister lahkub — on see halb: seadme seiskamine, administraatorid pingutavad serverit üles. Mida teha? Reserveerida meister. Minu kolleeg Pavel on sellest juba kirjutanud, , ma ei hakka seda kordama. Selle asemel räägin, miks vajate kindlasti MySQLi orkestraatorit!
Alustame peamisest küsimusest: „Kuidas me koodi uuele masinale ümber lülitame, kui meister lahkub?“
- VIP (Virtuaal IP) skeem meeldib mulle kõige rohkem, sellest räägime allpool. See on kõige lihtsam ja ilmsem, kuigi sellel on selge piirang: meister, mida me reserveerime, peab olema L2-segmendis uue masinaga, see tähendab, et teist andmekeskust võib unustada. Ja õigupoolest, kui järgida reeglit, et suur L2 on kuri, sest L2 on ainult racki jaoks, ning rackide vahel on L3, siis sellisel skeemil on veelgi rohkem piiranguid.
- DNS-nime saab koodi sisse kirjutada ja seda lahendada läbi /etc/hosts. Tegelikult ei toimu lahendamist. Skeemi eelis: puudub piirang, mis iseloomustab esimest meetodit, st ristsuundade korraldamine on võimalik. Kuid siis tekib ilmne küsimus, kui kiiresti me läbi Puppet-Ansible muudatusi /etc/hosts-i toome.
- Teist meetodit on võimalik veidi muuta: kõigile veebiserveritele installime vahemälu DNS-i, läbi mille kood liigub põhjaandmebaasi. Selle kirje jaoks DNS-is saab määrata TTL-i 60. Tundub, et õige rakendamise korral on meetod hea.
- Teenuse avastamise skeem, mis eeldab Consuli ja etcd kasutamist.
- Huvitav variant . Kõik MySQL-i liiklus tuleb suunata läbi ProxySQL-i, ProxySQL suudab ise määrata, kes on praegu peamine. Muide, ühe variandi kasutamise kohta selle toote osas saab lugeda minu .
Autori Orchestrator, töötades Githubis, rakendas esmalt esimest skeemi VIP-iga, seejärel muutis selle üle Consulile.
Tüüpiline infrastruktuuri skeem:
Kirjeldan kohe ilmselgeid olukordi, mida tuleb arvesse võtta:
- VIP-aadress ei tohi olla konfigureeritud ühelgi serveril. Kujutage ette olukorda: maestro taaskäivitus, ja seni kuni ta laadib, Orchestrator läks failover-režiimi ja tegi ühe slave'i meesterolliks; seejärel käivitus vana maestro ja nüüd on VIP kahel masinal. See on halb.
- Orkestratori jaoks tuleb kirjutada skript, mis pöördub vana maestro ja uue maestro poole. Vanal tuleb käivitada ifdown ja uuel maestro poole ifup vip. Hea oleks, kui see skript sisaldaks ka, et failover'i korral vana maestro lülitab lihtsalt pordi välja, et vältida splitbrain'i.
- Pärast seda, kui Orchestrator kutsus teie skripti, et esmalt eemaldada VIP ja/või lülitada pordid lülitil välja, ning seejärel uue maestro peal VIP-i üles tõsta, ärge unustage käsuga arping teatada kõigile, et uus VIP on nüüd siin.
- Kõigil slave'idel peab olema read_only=1, ja kui edutate slave'i meesterolliks, peab selle seadistuseks olema read_only=0.
- Pidage meeles, et meesteriks võib saada ükskõik milline slave, kelle me selleks valisime (Orchestratoril on terve mehhanism, et määrata, milline slave on kõigepealt kandidaat uueks meistriks, milline teiseks ning milline slave ei tohi mingil juhul meister olla). Kui slave saab meistriks, jääb sellele failide koormus ning lisandub veel meistri koormus, seda tuleb arvesse võtta.
Miks on Orchestrator teid hädasti vajalik, kui teil seda ei ole?
- Orchestratoril on väga mugav kasutajaliides, mis kuvab kogu topoloogia (vaadake allolevat ekraanikuva).
- Orchestrator suudab jälgida, millised slaves on maha jäänud, ja kus replikatsioon on täielikult katkenud (meil on Orchestratorile ühendatud skriptid SMS-ide saatmiseks).
- Orchestrator ütleb teile, millistel slaves on GTID errant viga.
Orchestratori liides:
Mis on GTID errant?
Orchestratori tööks on kaks peamist nõuet:
- Kõikides MySQL-klastri masinates peab olema sisse lülitatud pseudo GTID, meil on GTID sisse lülitatud.
- Peate olema veendunud, et igas kohas oleks sama tüüpi bin-logid, näiteks statement. Meil oli selline konfiguratsioon, kus peamastern ja enamus slave'dest kasutavad Row-logs, kuid kahes sünkroonimise ajal jäi kasutusele Mixed-režiim. Seetõttu ei soovinud Orchestrator nende slave'idega uut masterit ühendada.
Pidage meeles, et production-slave'i kõige olulisem aspekt on selle järjepidevus peamastri suhtes! Kui nii peamastris kui slave'is on lubatud Global Transaction ID (GTID), siis funktsiooni gtid_subset abil saate teada, kas nendel masinatel on tegelikult teostatud samad andme muutmise päringud. Lisainfot selle kohta leiate siit. .
Seega teavitab Orchestrator teid GTID errant veateate kaudu, et slave'is on tehingud, mida peamastris ei eksisteeri. Miks see nii juhtub?
- Slave'is ei ole lubatud read_only=1, keegi on sisse logitud ja teinud andme muutmise päringu.
- Slave'is ei ole lubatud super_read_only=1, seega on administraator, segades serverid, sisse loginud ja seal päringu teinud.
- Kui olete mõlemad eelnevad punktid arvesse võtnud, siis on veel üks trikk: MySQL-is läheb flusheeritavate binlogide päring samuti binlogi, mistõttu ilmneb esimese flushi käigus masteril ja kõigil saldositel GTID errant. Kuidas seda vältida? Versioonis perona-5.7.25-28 on lisatud seade binlog_skip_flush_commands=1, mis keelab flushi kirjutamise binlogidesse. Rohkem teavet leiate mysql.com veebisaidilt. .
Kokkuvõtteks. Kui te ei soovi kasutada Orchestratorit failover režiimis, seadke see jälgimisrežiimile. Siis on teil alati silme ees MySQL-masinate suhtlemise kaart ja selge teave selle kohta, millist replikatsiooni tüüp iga masin kasutab, kas saldosid mahajääb ning mis kõige tähtsam — kui kooskõlastatud nad masteriga on!
Ilmselt on küsimus: „Kuidas Orchestrator peaks tööle hakkama?“. Ta peab valima uue meistri olemasolevatest slavesidest ja seejärel ühendama kõik slavesid temaga (just selle jaoks on vajalik GTID; kui kasutada vana mehhanismi binlog_name ja binlog_pos, siis ei ole slave'i vahetamine praeguselt meistrilt uuele lihtsalt võimalik!). Enne, kui Orchestrator meie juurde tuli, pidin ma kunagi kogu seda tööd käsitsi tegema. Vana meester töötas halva Adaptec'i kontrolleri tõttu, tal oli umbes 10 slaves. Mul tuli viia VIP meistrilt ühe slave'i peale ja ühendada kõik ülejäänud slavesid temaga. Kui palju konsoole ma pidin avama, kui palju samal ajal käske sisestama... Pidin ootama kella 3-ani öösel, eemaldama koormuse kõigilt slavesidelt, välja arvatud kahest, tegema esimesest masinast meistri, kohe ühendada see teise masinaga, et pärast uue meistri juurde ühendada kõik teised slaves ja taastada koormus. Ühesõnaga, õudus...
Kuidas Orchestrator töötab, kui see läheb failover-režiimi? Seda on kõige lihtsam demonstreerida olukorra näitel, kus soovime teha meistriks võimsamat ja uuemat masinat kui praegu.
Joonisel on näidatud protsessi keskosa. Mis on selleks hetkeks juba tehtud? Ütlesime, et soovime muuta ühe slave uueks masteriks, Orchestrator hakkas lihtsalt kõiki teisi slave ühendama temaga, samal ajal kui uus master täidab vahemasina rolli. Sellise skeemi puhul ei esine vigu, kõik slave töötavad, Orchestrator eemaldab VIP-i vanalt masterilt, viib selle uuele, muudab read_only=0 ja unustab vana masteri. Kõik! Meie teenuse peatumisaeg on VIP-i üleviimise aeg, see on 2-3 sekundit.
Täna on kõik, aitäh kõigile. Varsti tuleb teine artikkel Orchestratorist. Ühes tuntud nõukogude filmis "Garaž" ütles üks kangelane: "Ma ei läheks temaga luurele!" Nii et Orchestrator, ma läheksin sinuga kindlasti luurele!
Allikas: habr.com
