U Citymobilu koristimo MySQL bazu podataka kao našu glavnu trajnu pohranu podataka. Imamo nekoliko klastera baza podataka za različite usluge i svrhe.

Stalna dostupnost mastera je kritičan pokazatelj performansi čitavog sistema i njegovih pojedinačnih delova. Automatski oporavak klastera u slučaju kvara glavnog računala uvelike smanjuje vrijeme odgovora na incident i vrijeme zastoja sistema. U ovom članku ću pogledati dizajn visoke dostupnosti (HA) za MySQL klaster zasnovan na MySQL Orchestrator i virtuelne IP adrese (VIP).

HA rješenje bazirano na VIP

Prvo ću vam ukratko reći šta je naš sistem za skladištenje podataka.

Koristimo klasičnu shemu replikacije s jednim masterom koji je dostupan za pisanje i više replika samo za čitanje. Klaster može sadržavati srednjeg mastera - čvor koji je i replika i master za druge. Klijenti pristupaju replikama putem HAProxy, što omogućava ravnomjernu distribuciju opterećenja i jednostavno skaliranje. Upotreba HAProxy-a je zbog istorijskih razloga, a mi smo trenutno u procesu migracije na ProxySQL.

Replikacija se izvodi u polusinhronom modu na osnovu GTID. To znači da barem jedna replika mora prijaviti transakciju prije nego što se smatra uspješnom. Ovaj način replikacije pruža optimalnu ravnotežu između performansi i sigurnosti podataka u slučaju kvara glavnog čvora. U osnovi, sve promjene se prenose sa mastera na replike pomoću Row Based Replication (RBR), ali neki čvorovi mogu imati mixed binlog format.

Orkestrator periodično ažurira stanje topologije klastera, analizira primljene informacije i ako se pojave problemi može pokrenuti automatsku proceduru oporavka. Programer je odgovoran za samu proceduru, jer se može implementirati na različite načine: bazirano na VIP-u, DNS-u, korištenjem servisa za otkrivanje usluga ili samostalno pisanim mehanizmima.

Jedan jednostavan način da vratite master ako ne uspije je korištenje plutajućih VIP adresa.

Šta trebate znati o ovom rješenju prije nego što krenete naprijed:

• VIP je IP adresa koja nije povezana sa određenim fizičkim mrežnim interfejsom. Ako čvor pokvari ili tokom planiranog održavanja, možemo prebaciti VIP na drugi resurs uz minimalno vrijeme zastoja.
• Oslobađanje i izdavanje virtuelne IP adrese je jeftina i brza operacija.
• Za rad sa VIP-om potreban vam je pristup serveru preko SSH-a ili korištenje posebnih uslužnih programa, na primjer, keepalived.

Pogledajmo moguće probleme s našim čarobnjakom i zamislimo kako bi mehanizam automatskog oporavka trebao funkcionirati.

Nestala je mrežna povezanost s masterom ili je nastao problem na hardverskom nivou, a server je nedostupan

1. Orkestrator ažurira topologiju klastera, svaka replika izvještava da je master nedostupan. Orkestrator započinje proces odabira replike prikladne za ulogu novog mastera i započinje oporavak.
2. Pokušavamo da skinemo VIP sa starog majstora - bezuspešno.
3. Replika se prebacuje na ulogu mastera. Topologija se obnavlja.
4. Dodavanje novog mrežnog interfejsa sa VIP-om. Pošto nije bilo moguće ukloniti VIP, počinjemo periodično slanje zahtjeva u pozadini gratuitous ARP. Ova vrsta zahteva/odgovora vam omogućava da ažurirate tabelu mapiranja IP i MAC adresa na povezanim prekidačima, čime vas obaveštavamo da se naš VIP pomerio. Ovo smanjuje vjerovatnoću split brain pri povratku starog majstora.
5. Sve nove veze se odmah preusmjeravaju na novi master. Stare veze ne uspijevaju i ponovljeni pozivi bazi podataka se vrše na razini aplikacije.

Server radi u normalnom režimu, došlo je do kvara na nivou DBMS-a

Algoritam je sličan prethodnom slučaju: ažuriranje topologije i pokretanje procesa oporavka. Pošto je server dostupan, uspešno otpuštamo VIP na starom masteru, prenosimo ga na novi i šaljemo nekoliko ARP zahteva. Mogući povratak starog mastera ne bi trebao utjecati na obnovljeni klaster i rad aplikacije.

Ostali problemi

Kvar replika ili srednjih majstora ne vodi na automatske radnje i zahtijeva ručnu intervenciju.

Virtuelni mrežni interfejs se uvek dodaje privremeno, odnosno, nakon ponovnog pokretanja servera, VIP se ne dodeljuje automatski. Svaka instanca baze podataka počinje u načinu samo za čitanje prema zadanim postavkama, orkestrator automatski prebacuje novi master za pisanje i pokušava instalirati read only na starog majstora. Ove radnje imaju za cilj smanjenje vjerovatnoće split brain.

Problemi mogu nastati tokom procesa oporavka, o čemu takođe treba obavijestiti orchestrator UI pored standardnih alata za praćenje. Proširili smo REST API dodavanjem ove funkcije (PR trenutno u fazi revizije).

Opšti dijagram HA rješenja je prikazan u nastavku.

Odabir novog majstora

Orkestrator je dovoljno pametan i pokušava da bira najpogodnija replika kao novi majstor prema sljedećim kriterijima:

• replika zaostaje za majstorom;
• MySQL verzija mastera i replike;
• tip replikacije (RBR, SBR ili mješoviti);
• lokacija u istim ili različitim data centrima;
• raspoloživost errant GTID — transakcije koje su izvršene na replici, a nisu na masteru;
• prilagođena pravila odabira se također uzimaju u obzir.

Nije svaki znak idealan kandidat za majstora. Na primjer, replika se može koristiti za sigurnosno kopiranje podataka ili server ima slabiju hardversku konfiguraciju. Orkestrator podržava ručna pravila pomoću kojih možete prilagoditi svoje preferencije odabira kandidata od najpoželjnijih do zanemarenih.

Odziv i vrijeme oporavka

U slučaju incidenta, važno je minimizirati vrijeme zastoja sistema, pa razmotrimo MySQL parametre koji utiču na kreiranje i ažuriranje topologije klastera od strane orkestratora:

• slave_net_timeout — broj sekundi tokom kojih replika čeka da novi podaci ili signal otkucaja srca stignu od mastera prije nego što se veza prepozna kao izgubljena i ponovo se poveže. Što je niža vrijednost, to brže replika može utvrditi da je komunikacija s masterom prekinuta. Ovu vrijednost postavljamo na 5 sekundi.
• MASTER_CONNECT_RETRY — broj sekundi između pokušaja ponovnog povezivanja. U slučaju problema s mrežom, niska vrijednost za ovaj parametar će omogućiti brzo ponovno povezivanje i spriječiti pokretanje procesa oporavka klastera. Preporučena vrijednost je 1 sekunda.
• MASTER_RETRY_COUNT — maksimalan broj pokušaja ponovnog povezivanja.
• MASTER_HEARTBEAT_PERIOD — interval u sekundama nakon kojeg master šalje signal otkucaja srca. Zadana vrijednost je polovina vrijednosti slave_net_timeout.

Opcije orkestratora:

• DelayMasterPromotionIfSQLThreadNotUpToDate - ako je jednak true, tada se glavna uloga neće primijeniti na repliku kandidata sve dok SQL nit replike ne završi sve neprimijenjene transakcije iz Relay Log-a. Koristimo ovu opciju da izbjegnemo gubitak transakcija kada sve replike kandidata zaostanu.
• InstancePollSeconds — učestalost izgradnje i ažuriranja topologije.
• RecoveryPollSeconds — učestalost topološke analize. Ako se otkrije problem, pokreće se oporavak topologije. Ovo konstantno, jednako 1 sekundi.

Svaki čvor klastera se ispituje od strane orkestratora jednom InstancePollSeconds sekundi Kada se otkrije problem, forsira se stanje klastera ažurirano, a zatim se donosi konačna odluka da se izvrši oporavak. Eksperimentirajući s različitim parametrima baze podataka i orkestratora, uspjeli smo smanjiti vrijeme odgovora i oporavka na 30 sekundi.

Test stalak

Počeli smo testirati HA šemu s razvojem lokalnog ispitni sto i dalju implementaciju u testnim i proizvodnim okruženjima. Lokalni štand je potpuno automatizovan na osnovu Docker-a i omogućava vam da eksperimentišete sa konfiguracijom orkestratora i mreže, skalirate klaster sa 2-3 servera na nekoliko desetina i izvodite vežbe u sigurnom okruženju.

Tokom vježbi biramo jednu od metoda emulacije problema: odmah pucajte u majstora koristeći kill -9, lagano prekinuti proces i zaustaviti server (docker-compose stop), simuliraju mrežne probleme koristeći iptables -j REJECT ili iptables -j DROP. Očekujemo sljedeće rezultate:

• orkestrator će otkriti probleme sa masterom i ažurirati topologiju za ne više od 10 sekundi;
• postupak oporavka će se automatski pokrenuti: mrežna konfiguracija će se promijeniti, uloga mastera će preći na repliku, topologija će biti ponovo izgrađena;
• novi master će postati upisiv, žive replike neće biti izgubljene tokom procesa rekonstrukcije;
• podaci će se početi upisivati ​​na novi master i replicirati;
• Ukupno vrijeme oporavka neće biti duže od 30 sekundi.

Kao što znate, sistem se može drugačije ponašati u testnim i proizvodnim okruženjima zbog različitih hardverskih i mrežnih konfiguracija, razlika u sintetičkom i stvarnom opterećenju, itd. Zbog toga periodično izvodimo vježbe u realnim uvjetima, provjeravajući kako se sistem ponaša kada se izgubi mrežna povezanost ili pojedini dijelovi degradiraju. U budućnosti želimo izgraditi potpuno identičnu infrastrukturu za oba okruženja i automatizirati njeno testiranje.

nalazi

Zdravlje čvora glavnog skladišnog sistema jedan je od glavnih ciljeva SRE i operativnog tima. Implementacija orkestratora i HA rješenja baziranog na VIP-u omogućila nam je postizanje sljedećih rezultata:

• pouzdano otkrivanje problema sa topologijom klastera baze podataka;
• automatska i brza reakcija na incidente vezane za master, smanjujući vreme zastoja sistema.

Međutim, rješenje ima svoja ograničenja i nedostatke:

• skaliranje HA šeme na nekoliko centara podataka će zahtijevati jednu L2 mrežu između njih;
• Prije dodjeljivanja VIP na novom masteru, moramo ga osloboditi na starom. Proces je sekvencijalan, što povećava vrijeme oporavka;
• Za otpuštanje VIP-a potreban je SSH pristup serveru, ili bilo koji drugi metod pozivanja udaljenih procedura. Budući da server ili baza podataka imaju probleme koji su uzrokovali proces oporavka, ne možemo biti sigurni da će se uklanjanje VIP-a uspješno završiti. A to može dovesti do pojave dva servera sa istom virtuelnom IP adresom i problema split brain.

Izbjeći split brain, možete koristiti metodu STONITH („Pucaj u drugi čvor u glavu“), što potpuno izoluje ili onemogućuje problemski čvor. Postoje i drugi načini za implementaciju visoke dostupnosti klastera: kombinacija VIP i DNS-a, usluga otkrivanja i proxy usluga, sinhrone replikacije i druge metode koje imaju svoje nedostatke i prednosti.

Govorio sam o našem pristupu kreiranju MySQL klastera za nadilaženje greške. Jednostavan je za implementaciju i pruža prihvatljiv nivo pouzdanosti u trenutnim uslovima. Kako se cijeli sistem općenito, a posebno infrastruktura razvijaju, ovaj pristup će nesumnjivo evoluirati.

izvor: www.habr.com