Orkestrator za MySQL: zašto ne možete napraviti projekat otporan na greške bez njega

Svaki veliki projekat je započeo sa nekoliko servera. Isprva je postojao jedan DB server, a zatim su mu dodani slave radi skaliranja očitavanja. A onda - stani! Postoji jedan gospodar, ali ima mnogo robova; ako jedan od robova ode, onda će sve biti u redu, ali ako master ode, bit će loše: zastoji, administratori pokušavaju podići server. sta da radim? Rezervišite majstora. O tome je već pisao moj kolega Pavel članak, neću ponavljati. Umjesto toga, reći ću vam zašto vam je definitivno potreban Orchestrator za MySQL!

Počnimo s glavnim pitanjem: "Kako ćemo prebaciti kod na novu mašinu kada gospodar ode?"

• Najviše mi se sviđa shema sa VIP (virtuelnim IP-om), o tome ćemo u nastavku. To je najjednostavniji i najočitiji, iako ima očigledno ograničenje: master koji ćemo rezervisati mora biti u segmentu L2 sa novom mašinom, odnosno možemo zaboraviti na drugi DC. I, na prijateljski način, ako se pridržavate pravila da je veliki L2 zao, jer je L2 samo po rack-u, a L3 između regala, a takva shema ima još više ograničenja.
• Možete napisati DNS ime u kodu i riješiti ga putem /etc/hosts. U stvari, neće biti rješenja. Prednost sheme: nema ograničenja karakteristika prve metode, odnosno moguće je organizirati unakrsni DC. Ali onda se postavlja očigledno pitanje: koliko brzo možemo isporučiti promjenu na /etc/hosts putem Puppet-Ansible?
• Drugi način možete malo promijeniti: instalirajte DNS za keširanje na sve web servere, 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, koja podrazumijeva korištenje Consul i etcd.
• Zanimljiva opcija sa ProxySQL. Morate usmjeriti sav promet na MySQL kroz ProxySQL; ProxySQL sam može odrediti tko je glavni. Inače, o jednoj od opcija za korištenje ovog proizvoda možete pročitati u mom članak.

Autor Orchestrator-a, koji radi u Githubu, prvo je implementirao prvu šemu sa VIP-om, a zatim je konvertovao u šemu sa konzulom.

Tipičan raspored infrastrukture:

Odmah ću opisati očigledne situacije koje treba uzeti u obzir:

• VIP adresa ne bi trebalo da bude registrovana u konfiguraciji ni na jednom serveru. Zamislimo situaciju: master se ponovo pokrenuo, i dok se učitavao, Orchestrator je otišao u režim prelaska na grešku i napravio jednog od slaveova za mastera; tada je ustao stari majstor, a sada je VIP na dva auta. Ovo je loše.
• Za orkestratora ćete morati napisati skriptu za pozivanje starog i novog majstora. Na starom masteru morate pokrenuti ifdown, a na novom masteru – ifup vip. Bilo bi lijepo uključiti u ovu skriptu da se u slučaju greške, port na starom glavnom prekidaču jednostavno isključuje kako bi se izbjegao bilo kakav splitbrain.
• Nakon što Orchestrator pozove vašu skriptu da prvo ukloni VIP i/ili ugasi port na prekidaču, a zatim pozove skriptu za podizanje VIP na novom masteru, ne zaboravite da koristite komandu arping da kažete svima da je novi VIP sada ovdje.
• Svi slaveovi bi trebali imati read_only=1, a čim unaprijedite slave u master, trebao bi imati read_only=0.
• Ne zaboravite da bilo koji rob kojeg smo odabrali za ovo može postati gospodar (Orkestrator ima cijeli mehanizam preferencija kojeg roba treba uzeti u obzir kao kandidata za novog gospodara na prvom mjestu, kojeg na drugom mjestu, a kojeg roba treba ni pod kojim okolnostima ne biti izabran master). Ako slave postane master, onda će opterećenje slavea ostati na njemu i opterećenje mastera će se dodati, to se mora uzeti u obzir.

Zašto vam treba Orchestrator ako ga nemate?

• Orchestrator ima grafičko sučelje vrlo jednostavno za upotrebu koje prikazuje cijelu topologiju (pogledajte snimku ekrana ispod).
• Orchestrator može pratiti koji slave zaostaju i gdje je replikacija generalno prekinuta (imamo skripte prikačene na Orchestrator za slanje SMS-a).
• Orchestrator vam govori koji slaveovi imaju grešku u GTID-u.

Interfejs orkestratora:

Šta je GTID pogrešan?

Postoje dva glavna uslova za rad Orkestratora:

• Neophodno je da pseudo GTID bude omogućen na svim mašinama u MySQL klasteru, imamo omogućen GTID.
• Neophodno je da svuda postoji jedna vrsta binlogova, možete koristiti naredbu. Imali smo konfiguraciju u kojoj su master i većina slave imali Row, a dva su istorijski ostala u Mixed modu. Kao rezultat toga, Orchestrator jednostavno nije želio povezati ove slave s novim masterom.

Zapamtite da je najvažnija stvar kod proizvodnog roba njegova dosljednost s masterom! Ako imate omogućen Globalni ID transakcije (GTID) i na glavnom i na slave-u, tada možete koristiti funkciju gtid_subset da saznate da li su isti zahtjevi za promjene podataka zaista izvršeni na ovim mašinama. Možete pročitati više o tome ovdje.

Stoga vam Orchestrator pokazuje kroz grešku GTID da postoje transakcije na slave-u koje nisu na master-u. Zašto se ovo dešava?

• Read_only=1 nije omogućeno na slave-u, neko se povezao i završio zahtjev za promjenu podataka.
• Super_read_only=1 nije omogućen na slave-u, tada je administrator, zbunivši server, ušao i tamo izvršio zahtjev.
• Ako ste uzeli u obzir obe prethodne tačke, onda postoji još jedan trik: u MySQL-u, zahtev za ispiranje binlogova takođe ide u binlog, tako da će se pri prvom čišćenju pojaviti greška GTID-a na master i svim slaveovima. Kako to izbjeći? Perona-5.7.25-28 je uvela binlog_skip_flush_commands=1 postavku, koja zabranjuje upisivanje flush-a u binlogs. Postoji jedan uspostavljen na web stranici mysql.com bug.

Dozvolite mi da sumiram sve gore navedeno. Ako još ne želite da koristite Orchestrator u režimu prelaska sa greške, onda ga stavite u režim posmatranja. Tada ćete uvijek imati pred očima mapu interakcije MySQL strojeva i vizualne informacije o tome kakav je tip replikacije na svakoj mašini, da li robovi zaostaju, i što je najvažnije, koliko su konzistentni sa masterom!

Očigledno pitanje je: "Kako Orchestrator treba da radi?" On mora izabrati novog mastera od trenutnih slave-ova, a zatim ponovo povezati sve slave-ove na njega (za ovo je potreban GTID; ako koristite stari mehanizam sa binlog_name i binlog_pos, zatim prebacite slave sa trenutnog mastera na novi jednostavno nemoguće!). Prije nego što smo imali Orchestrator, jednom sam sve ovo morao raditi ručno. Stari gospodar je visio zbog pokvarenog Adaptec kontrolera; imao je oko 10 robova. Trebao sam prenijeti VIP sa glavnog na jednog od slaveova i ponovo povezati sve ostale slave na njega. Koliko sam konzola morao da otvorim, koliko simultanih komandi sam uneo... Morao sam da sacekam do 3 sata ujutro, skinem teret sa svih slave-ova osim dva, napravim prvu masinu od dva mastera, odmah prikljucim drugu masinu na njega, pa priključite sve ostale slave na novi master i vratite teret. Generalno, užasno...

Kako Orchestrator radi kada pređe u režim prelaska sa greške? To se najlakše ilustruje primjerom situacije u kojoj želimo da od majstora napravimo moćniju, moderniju mašinu nego što imamo sada.

Slika prikazuje sredinu procesa. Šta je do sada već urađeno? Rekli smo da želimo da neki slave bude novi master, Orchestrator je počeo jednostavno da ponovo povezuje sve druge slave na njega, pri čemu je novi master delovao kao tranzitna mašina. Sa ovom šemom ne dolazi do grešaka, svi slave-ovi rade, Orchestrator uklanja VIP sa starog mastera, prenosi ga na novi, pravi read_only=0 i zaboravlja na stari master. Sve! Vrijeme zastoja 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 tobom u izviđanje!

izvor: www.habr.com