Svaki veliki projekt započeo je s nekoliko poslužitelja. Isprva je postojao jedan DB poslužitelj, a zatim su mu dodani robovi za skaliranje očitanja. A onda – stani! Jedan je gospodar, a mnogo je robova; ako jedan od robova ode, onda će sve biti u redu, ali ako master ode, bit će loše: prekid rada, admini pokušavaju podići server. Što uraditi? Rezervirajte majstora. Kolega Pavel je već pisao o tome , neću ponavljati. Umjesto toga, reći ću vam zašto vam definitivno treba Orchestrator za MySQL!
Počnimo s glavnim pitanjem: "Kako ćemo prebaciti kod na novi stroj kada master ode?"
- Najviše mi se sviđa shema s VIP-om (virtualni IP), o kojoj ćemo govoriti u nastavku. Najjednostavniji je i najočitiji, iako ima očito ograničenje: master koji ćemo rezervirati mora biti u L2 segmentu s novim strojem, odnosno možemo zaboraviti na drugi DC. I, na prijateljski način, ako slijedite pravilo da je veliki L2 zlo, jer L2 je samo po stalku, a L3 je između stalaka, a takva shema ima još više ograničenja.
- Možete napisati DNS ime u kodu i riješiti ga kroz /etc/hosts. Zapravo, neće biti rješenja. Prednost sheme: nema ograničenja karakterističnih za prvu metodu, odnosno moguće je organizirati cross-DC. Ali tada se postavlja očito pitanje: koliko brzo možemo isporučiti promjenu u /etc/hosts putem Puppet-Ansible?
- Drugu metodu možete malo promijeniti: instalirajte DNS za predmemoriju na sve web poslužitelje, preko kojih će kod ići u glavnu bazu podataka. Možete postaviti TTL 60 za ovaj unos u DNS-u. Čini se da je metoda dobra ako se pravilno implementira.
- Shema s otkrivanjem usluge, što podrazumijeva korištenje Consul-a i sl.
- Zanimljiva opcija sa . Morate usmjeriti sav promet na MySQL kroz ProxySQL; ProxySQL sam može odrediti tko je glavni. Usput, o jednoj od mogućnosti korištenja ovog proizvoda možete pročitati u mom .
Autor Orchestratora, radeći u Githubu, prvo je implementirao prvu shemu s VIP-om, a zatim ju je pretvorio u shemu s konzulom.
Tipični raspored infrastrukture:
Odmah ću opisati očite situacije koje treba uzeti u obzir:
- VIP adresa ne bi trebala biti registrirana u konfiguraciji ni na jednom poslužitelju. Zamislimo situaciju: master se ponovno digao, i dok se učitavao, Orchestrator je prešao u failover mod i napravio jednog od slave-a masterom; tada se digao stari majstor, a sada je VIP na dva auta. To je loše.
- Za orkestraša ćete morati napisati scenarij za pozivanje starog i novog majstora. Na starom masteru morate pokrenuti ifdown, a na novom masteru – ifup vip. Bilo bi lijepo također uključiti u ovu skriptu da se u slučaju failovera port na starom glavnom prekidaču jednostavno isključi kako bi se izbjegao bilo kakav splitbrain.
- Nakon što Orchestrator pozove vašu skriptu da prvo ukloni VIP i/ili ugasi port na preklopniku, a zatim pozove skriptu za podizanje VIP-a na novom masteru, ne zaboravite upotrijebiti naredbu arping da svima kažete da je novi VIP sada ovdje.
- Svi podređeni uređaji trebali bi imati read_only=1, a čim promaknete podređeni u nadređeni, on bi trebao imati read_only=0.
- Ne zaboravite da svaki rob kojeg smo za to odabrali može postati gospodar (Orchestrator ima cijeli mehanizam preferiranja kojeg će roba smatrati kandidatom za novog gospodara na prvom mjestu, kojeg na drugom mjestu, a kojeg roba treba uopće ne biti odabran ni pod kojim okolnostima gospodar). Ako slave postane master, onda će opterećenje slave ostati na njemu i dodati će se opterećenje mastera, to se mora uzeti u obzir.
Zašto vam treba Orchestrator ako ga nemate?
- Orchestrator ima vrlo jednostavno grafičko sučelje koje prikazuje cijelu topologiju (pogledajte snimak zaslona u nastavku).
- Orchestrator može pratiti koji robovi zaostaju i gdje se replikacija općenito pokvarila (imamo skripte priložene Orchestratoru za slanje SMS-a).
- Orchestrator vam govori koji robovi imaju pogrešan GTID.
Orchestrator sučelje:
Što je GTID errant?
Postoje dva glavna zahtjeva za Orchestrator za rad:
- Potrebno je da pseudo GTID bude omogućen na svim strojevima u MySQL klasteru; mi imamo uključen GTID.
- Potrebno je da posvuda postoji jedna vrsta binloga, možete koristiti statement. Imali smo konfiguraciju u kojoj su glavni i većina robova imali red, a dva su povijesno ostala u mješovitom načinu rada. Kao rezultat toga, Orchestrator jednostavno nije želio povezati ove robove s novim gospodarom.
Zapamtite da je najvažnija stvar u proizvodnom robu njegova dosljednost gospodaru! Ako imate omogućen ID globalne transakcije (GTID) i na glavnom i na podređenom računalu, tada možete upotrijebiti funkciju gtid_subset kako biste saznali jesu li isti zahtjevi za promjenama podataka stvarno izvršeni na tim strojevima. Možete pročitati više o ovome .
Dakle, Orchestrator vam kroz GTID errant pokazuje da postoje transakcije na podređenom uređaju koje nisu na glavnom. Zašto se ovo događa?
- Read_only=1 nije omogućen na slave uređaju, netko se povezao i dovršio zahtjev za promjenu podataka.
- Super_read_only=1 nije omogućen na podređenom uređaju, tada je administrator, nakon što je zbunio poslužitelj, ušao i tamo izvršio zahtjev.
- Ako ste uzeli u obzir obje prethodne točke, onda postoji još jedan trik: u MySQL-u zahtjev za ispiranjem binlogova također ide u binlog, tako da će se pri prvom ispiranju GTID errant pojaviti na glavnom i svim podređenim uređajima. Kako to izbjeći? Perona-5.7.25-28 uvela je postavku binlog_skip_flush_commands=1, koja zabranjuje ispiranje u binlogove. Postoji uspostavljena na web stranici mysql.com .
Dopustite mi da sumiram sve gore navedeno. Ako još ne želite koristiti Orchestrator u failover modu, stavite ga u promatrački mod. Tada ćete uvijek pred očima imati mapu interakcije MySQL strojeva i vizualne informacije o tome koja je vrsta replikacije na svakom stroju, zaostaju li podređeni uređaji, i što je najvažnije, koliko su dosljedni glavnom!
Očigledno pitanje je: "Kako Orchestrator treba raditi?" On mora odabrati novi glavni među trenutnim podređenim uređajima, a zatim ponovno spojiti sve podređene uređaje na njega (za ovo je potreban GTID; ako koristite stari mehanizam s binlog_name i binlog_pos, prebacite podređeni uređaj s trenutnog glavnog na novi je jednostavno nemoguće!). Prije nego što smo imali Orchestrator, jednom sam sve ovo morao raditi ručno. Stari master je visio zbog bugovanog Adaptec kontrolera, imao je 10ak slave-ova. Trebao sam prenijeti VIP s glavnog na jedan od podređenih i ponovno spojiti sve ostale podređene na njega. Koliko sam konzola morao otvoriti, koliko sam simultanih komandi unio... Morao sam čekati do 3 ujutro, maknuti teret sa svih slave osim dva, napraviti prvi stroj od dva mastera, odmah prikačiti drugi stroj na njega, pa pričvrstite sve ostale robove novom gospodaru i vratite teret. Sve u svemu, strašno...
Kako radi Orchestrator kada prijeđe u failover mod? To je najlakše ilustrirati na primjeru situacije u kojoj od mastera želimo napraviti moćniji, moderniji stroj nego što imamo sada.
Slika prikazuje sredinu procesa. Što je već učinjeno do sada? Rekli smo da želimo učiniti nekog roba novim gospodarom, Orchestrator je počeo jednostavno ponovno povezivati sve ostale robove s njim, s novim gospodarom koji djeluje kao tranzitni stroj. S ovom shemom se ne pojavljuju greške, svi slave rade, Orchestrator uklanja VIP sa starog mastera, prebacuje ga na novi, pravi read_only=0 i zaboravlja na starog mastera. Svi! Zastoj naše usluge je vrijeme VIP transfera, koje iznosi 2-3 sekunde.
To je sve za danas, hvala svima. Uskoro će biti drugi članak o Orchestratoru. U poznatom sovjetskom filmu "Garaža" jedan lik je rekao: "Ne bih išao s njim u izviđanje!" Dakle, orkestratoru, ja bih išao s vama u izviđanje!
Izvor: www.habr.com