Iga suur projekt alustas paarist serverist. Alguses oli üks DB-server, hiljem lisandusid klounid, et lugemist skaleerida. Ja siis - stopp! Meistrid on üks, klounid palju; kui üks klounidest kaob, siis on kõik hästi, aga kui Meister kaob - on halb: seisak, administraatorid kiirustavad serveri taastamisega. Mida teha? Reserveerida Meister. Minu kolleeg Pavel on sellest juba kirjutanud , ma ei kavatse seda korrata. Selle asemel räägin, miks teil on kindlasti vaja Orchestratorit MySQL jaoks!
Alustame peamisest küsimusest: "Kuidas me lülitame koodi uuele masinale meistri kadumisel?".
- Skeem VIP (Virtuaalne IP) meeldib mulle kõige rohkem, sellest räägime allpool. See on kõige lihtsam ja ilmsem, kuigi sellel on üks selge piirang: meister, mida me reserveerime, peab asuma L2-segmendis uue masinaga, seega võib teise andmekeskuse unustada. Ja kui aus olla, kui järgida reeglit, et suur L2 on kurjus, kuna L2 on ainult rack'i jaoks, ja rack'ide vahel on L3, siis selline skeem toob kaasa veel rohkem piiranguid.
- Saame koodis määrata DNS-nime ja resolverida selle kaudu /etc/hosts. Tegelikult resolveri ei toimu. Skeemi eelis: piirang, mis iseloomustab esimest võimalust, puudub, see tähendab, et saame korraldada ülevahetusi ka vaheandmekeskustes. Kuid siis tekib selge küsimus, kui kiiresti me läbi Puppet-Ansible muudatuse /etc/hosts toome.
- Teist meetodit on võimalik veidi muuta: paigaldame kõikidele veebiserveritele vahemälu DNS, mille kaudu kood jõuab meistri andmebaasi. Selle kirje TTL võiks olla 60 DNS-is. Tundub, et korraliku teostuse korral on meetod hea.
- Teenuse avastamise skeem, mis hõlmab Consuli ja etcd rakendamist.
- Huvi pakkuv variant . Kogu liiklus MySQL-i suunatakse läbi ProxySQL-i, ProxySQL oskab ise tuvastada, kes on praegu meister. Muide, ühe selle toote kasutusvõimaluse kohta saab lugeda minu .
Orchestratori autor, töötades Githubis, rakendas esmalt esimese skeemi VIP, seejärel kohandas selle skeemiks koos consuliga.
Tüüpiline infrastruktuuri skeem:
Kirjeldan kohe ilmseid olukordi, mida tuleb arvestada:
- VIP-aadress ei tohiks olla konfigureeritud üheski serveris. Kujutame ette olukorda: meister taaskäivitub, ja seni kuni ta käivitub, läks Orchestrator faileedrežiimi ja tegi ühest klounidest meistri; seejärel käivitati vana meister, ja nüüd on VIP kahel masinal. See on halb.
- Orkestratori jaoks tuleb kirjutada skript vana ja uue meistri poole pöördumiseks. Vanal tuleb käivitada ifdown ja uuel meistril — ifup vip. Häid oleks lisada skripti, et juhul, kui toimub failover, lülitatakse vana meistri lüliti port lihtsalt välja, et vältida igasugust splitbrain'i.
- Pärast seda, kui Orkestrator on käivitanud teie skripti, et kõigepealt eemaldada VIP ja/või lülitada sisse lüliti port, ja seejärel uuel meistril käivitada VIP tõstmise skripti, ärge unustage käsuga arping kõigile teatada, et uus VIP on nüüd siin.
- Küsimus on, et kõigil släbidel peab olema read_only=1, ja kui te edutate släbi meistriks, peab sellel olema read_only=0.
- Ärge unustage, et meistriks võib saada iga släbi, mille oleme selleks valinud (Orkestratoril on terve mehhanism, et eelistada, milline släbi peaks kõigepealt kandidaadiks uueks meistriks, milline teiseks ja milline släbi ei tohi mingil juhul meistriks olla valitud). Kui släbi saab meistriks, jääb sellel släbi koormus ja lisandub meistri koormus, seda tuleb arvesse võtta.
Miks vajate Orkestratorit, kui teil seda pole?
- Orkestratoril on väga mugav graafiline kasutajaliides, mis kuvab kogu topoloogiat (vaadake allolevat ekraanipilti).
- Orkestrator suudab jälgida, millised släbid on mahajäänud, ja kus replikatsioon on täiesti katkenud (meil on Orkestratoriga seotud skriptid SMS-ide saatmiseks).
- Orkestrator ütleb teile, millistel släbidel on GTID errant viga.
Orkestratori liides:
Mis on GTID errant?
Orkestratoril on kaks peamist nõuet:
- Kõigil MySQL-klastrite masinatel peab olema sisse lülitatud pseudo GTID, meil on sisse lülitatud GTID.
- Kuskil peab olema sama tüüpi binlogid, võib olla statement. Meil oli selline konfiguratsioon, kus meistril ja enamikel släbidel oli Row, kuid kahel ajal jäi Mixed-režiim. Tulemuseks on see, et Orkestrator ei soovinud neid släbisid uue meistriga ühendada.
Pidage meeles, et kõige olulisem asjaolu production-släbis on selle järjepidevus meistriga! Kui nii meistril kui ka släbil on sisse lülitatud Global Transaction ID (GTID), siis funktsiooni gtid_subset kaudu saate teada, kas samad andmete muutmise päringud on nende masinatega tõeliselt täidetud. Selle kohta saate lugeda rohkem. .
Seega Orchestrator näitab teile GTID errant veateate kaudu, et teisel on tehingud, mida peameistril ei ole. Miks see nii juhtub?
- Teisel pole seatud read_only=1, keegi on sisse logitud ja tegi andmete muutmise päringu.
- Teisel pole seatud super_read_only=1, seega administraator, kes segas serverit, logis sisse ja tegi seal päringu.
- Kui olete arvesse võtnud mõlemat eelnevat punkti, siis on veel üks nipp: MySQL-is satub päring бинлогide flushimise kohta samuti бинлогisse, mistõttu igal esimesel flush'il meistril ja kõigil teistel ilmub GTID errant. Kuidas seda vältida? perona-5.7.25-28 on ilmunud seadistus binlog_skip_flush_commands=1, mis keelab flush'i kirjutamise бинлогidesse. mysql.com lehelt leiate selle kohta teavet. .
Kokkuvõtteks, kui te praegu ei soovi kasutada Orchestratorit failover režiimis, siis seadke see jälgimisrežiimi. Sellisel juhul on teil alati silme ees MySQL-masinate töökaardid ja selge teave selle kohta, millist tüüpi replikatsioon on igas masinas, kas teised jäävad maha ning mis kõige tähtsam — kui järkjärgulised nad on meistriga!
Ilmselt on küsimus: "Kuidas peaks Orchestrator töötama?". Ta peaks valima uue meistri olemasolevate teiselt ja seejärel ühendama kõik teised selle külge (selle jaoks on vajalik GTID; kui kasutada vana mehhanismi binlog_name ja binlog_pos, siis ei ole võimalik vahetada teisi meistrilt uuele!). Enne, kui meil Orchestrator ilmus, tuli mul seda kord käsitsi teha. Vana meister seisis Adapteci veaga kontrolleri tõttu ja tal oli umbes 10 teist. Mul tuli VIP teisaldada meistrilt ühe teise külge ja kõik teised selle külge ümber ühendada. Kui palju konsoole pidin avama, kui palju samasuguseid käske sisestama... Pidin ootama kuni kella 3-ni öösel, et koormust eemaldada kõigilt teistelt, välja arvatud kahest, teha esimesest masinast meister, kohe ühendada teise masinaga, seejärel ühendada kõik teised teise meistriga ja koormus tagasi anda. Ühesõnaga, õudus...
Kuidas Orchestrator töötab, kui see läheb failover režiimi? Seda on kõige lihtsam näidata olukorra näite kaudu, kui me tahame teha meistriks võimsama, kaasaegsema masina kui see, mis on hetkel.
Kujutiselt on esitatud protsessi keskpunkt. Mida on enne seda hetke tehtud? Me ütlesime, et soovime muuta mingi kliente uueks peajuhiks, Orchestrator hakkas lihtsalt kõiki teisi kliente ümber lülitama, samal ajal kui uus peajuhiks toimib ülemineku masinana. Selle skeemi puhul ei teki vigu, kõik kliendid töötavad, Orchestrator eemaldab VIP-i vanalt peajuhikult, kannab selle uuele, seab read_only=0 ja unustab vanast peajuhist. Kõik! Meie teenuse seisak on VIP-i üleviimise aeg, see on 2-3 sekundit.
Tänaseks on kõik, aitäh kõigile. Peagi tuleb teine artikkel Orchestratorist. Ühes kuulsas Nõukogude filmis "Garaazh" ütles üks tegelane: "Ma ei läheks temaga luurele!" Noh, Orchestrator, mina läheks sinuga luurele!
Allikas: habr.com
