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

Stalna dostupnost mastera kritičan je pokazatelj performansi cijelog sustava i njegovih pojedinačnih dijelova. Automatski oporavak klastera u slučaju kvara mastera uvelike smanjuje vrijeme odgovora na incident i vrijeme prekida rada sustava. U ovom ću članku pogledati dizajn visoke dostupnosti (HA) za MySQL klaster koji se temelji na MySQL orkestrator i virtualne IP adrese (VIP).

HA rješenje temeljeno na VIP-u

Prvo ću vam ukratko reći što je naš sustav za pohranu podataka.

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

Replikacija se izvodi u polusinkronom načinu rada na temelju GTID. To znači da barem jedna replika mora zabilježiti 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. Uglavnom se sve promjene prenose s glavnog na replike pomoću Row Based Replication (RBR), ali neki čvorovi mogu imati mixed binlog format.

Orkestrator povremeno ažurira stanje topologije klastera, analizira primljene informacije, a ako se pojave problemi, može pokrenuti postupak automatskog oporavka. Programer je odgovoran za samu proceduru, budući da se ona može implementirati na različite načine: na temelju VIP-a, DNS-a, korištenjem servisa za otkrivanje servisa ili samonapisanih mehanizama.

Jedan jednostavan način za vraćanje mastera ako ne uspije je korištenje plutajućih VIP adresa.

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

VIP je IP adresa koja nije povezana s određenim fizičkim mrežnim sučeljem. Ako čvor zakaže ili tijekom planiranog održavanja, VIP možemo prebaciti na drugi resurs uz minimalno vrijeme zastoja.
Oslobađanje i izdavanje virtualne IP adrese jeftina je i brza operacija.
Za rad s VIP-om potreban vam je pristup poslužitelju putem SSH-a ili korištenje posebnih uslužnih programa, na primjer, keepalived.

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

Mrežna povezanost s masterom je nestala ili se pojavio problem na razini hardvera, a poslužitelj je nedostupan

Orkestrator ažurira topologiju klastera, svaka replika javlja da je master nedostupan. Orkestar započinje proces odabira replike prikladne za ulogu novog majstora i započinje oporavak.
Pokušavamo skinuti VIP sa starog majstora - bez uspjeha.
Replika prelazi u ulogu majstora. Topologija se ponovno gradi.
Dodavanje novog mrežnog sučelja s VIP-om. Budući da nije bilo moguće ukloniti VIP, počinjemo povremeno slati zahtjev u pozadini besplatni ARP. Ova vrsta zahtjeva/odgovora omogućuje vam ažuriranje tablice mapiranja IP i MAC adresa na povezanim preklopnicima, čime vas obavještava da se naš VIP preselio. Ovo smanjuje vjerojatnost split brain prilikom vraćanja starog majstora.
Sve nove veze odmah se preusmjeravaju na novi master. Stare veze ne uspijevaju i ponovljeni pozivi bazi podataka vrše se na razini aplikacije.

Poslužitelj radi u normalnom načinu rada, došlo je do kvara na razini DBMS-a

Algoritam je sličan prethodnom slučaju: ažuriranje topologije i pokretanje procesa oporavka. Budući da je poslužitelj dostupan, uspješno oslobađamo VIP na starom masteru, prenosimo ga na novi i šaljemo nekoliko ARP zahtjeva. Eventualni povratak starog mastera ne bi trebao utjecati na obnovljeni klaster i rad aplikacije.

Ostali problemi

Neuspjeh replika ili međumastera ne vodi automatskim radnjama i zahtijeva ručnu intervenciju.

Virtualno mrežno sučelje uvijek se dodaje privremeno, to jest, nakon ponovnog pokretanja poslužitelja, VIP se ne dodjeljuje automatski. Svaka instanca baze podataka prema zadanim postavkama pokreće se u načinu samo za čitanje, orkestrator automatski prebacuje novi master na pisanje i pokušava instalirati read only na starog majstora. Ove radnje imaju za cilj smanjiti vjerojatnost split brain.

Problemi se mogu pojaviti tijekom procesa oporavka, o čemu bi se također trebalo obavijestiti putem korisničkog sučelja orkestratora uz standardne alate za nadzor. Proširili smo REST API dodavanjem ove značajke (PR trenutno u reviziji).

Opći dijagram rješenja HA prikazan je u nastavku.

Odabir novog majstora

Orkestar je dovoljno pametan i pokušava birati najprikladnija replika kao novi majstor prema sljedećim kriterijima:

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

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

Vrijeme odziva i oporavka

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

slave_net_timeout — broj sekundi tijekom kojih replika čeka da stignu novi podaci ili signal otkucaja srca od mastera prije nego što se veza prepozna kao izgubljena i ponovno uspostavi. Što je niža vrijednost, replika brže 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 ovog parametra omogućit će brzo ponovno povezivanje i spriječiti pokretanje procesa oporavka klastera. Preporučena vrijednost je 1 sekunda.
MASTER_RETRY_COUNT — najveći broj pokušaja ponovnog povezivanja.
MASTER_HEARTBEAT_PERIOD — interval u sekundama nakon kojeg master šalje signal otkucaja srca. Zadana vrijednost je pola vrijednosti slave_net_timeout.

Parametri orkestratora:

DelayMasterPromotionIfSQLThreadNotUpToDate - ako je jednak true, tada glavna uloga neće biti primijenjena na repliku kandidata dok SQL nit replike ne dovrši sve neprimijenjene transakcije iz Dnevnika releja. Ovu opciju koristimo kako bismo izbjegli gubitak transakcija kada sve replike kandidata zaostaju.
InstancePollSeconds — učestalost izgradnje i ažuriranja topologije.
RecoveryPollSeconds — učestalost analize topologije. Ako se otkrije problem, pokreće se oporavak topologije. Ovaj konstantno, jednako 1 sekundi.

Orkestrator ispituje svaki čvor klastera jednom InstancePollSeconds sekundi Kada se otkrije problem, forsira se stanje klastera ažurirano, a zatim se donosi konačna odluka o izvođenju oporavka. Eksperimentiranjem s različitim parametrima baze podataka i orkestratora, uspjeli smo smanjiti vrijeme odgovora i oporavka na 30 sekundi.

Ispitno postolje

Započeli smo testiranje HA sheme s razvojem lokalnog testna klupa te daljnju implementaciju u testnim i proizvodnim okruženjima. Lokalno postolje potpuno je automatizirano temeljeno na Dockeru i omogućuje vam eksperimentiranje s konfiguracijom orkestratora i mreže, skaliranje klastera s 2-3 poslužitelja na nekoliko desetaka i provođenje vježbi u sigurnom okruženju.

Tijekom vježbi odabiremo jednu od metoda emulacije problema: trenutno pucamo na majstora pomoću kill -9, lagano prekinuti proces i zaustaviti poslužitelj (docker-compose stop), simulirajte mrežne probleme pomoću iptables -j REJECT ili iptables -j DROP. Očekujemo sljedeće rezultate:

orkestrator će otkriti probleme s masterom i ažurirati topologiju za najviše 10 sekundi;
automatski će se pokrenuti postupak oporavka: mrežna konfiguracija će se promijeniti, uloga mastera prijeći će na repliku, topologija će se ponovno izgraditi;
novi master će postati pisan, žive replike neće biti izgubljene tijekom procesa obnove;
podaci će se početi upisivati u novi master i replicirati;
Ukupno vrijeme oporavka neće biti dulje od 30 sekundi.

Kao što znate, sustav se može ponašati drugačije u testnom i proizvodnom okruženju zbog različitih hardverskih i mrežnih konfiguracija, razlika u sintetičkom i stvarnom opterećenju itd. Stoga povremeno provodimo vježbe u stvarnim uvjetima, provjeravajući kako se sustav ponaša kada se mrežna povezanost izgubi ili su njegovi pojedini dijelovi degradirani. U budućnosti želimo izgraditi potpuno identičnu infrastrukturu za oba okruženja i automatizirati njezino testiranje.

Zaključci

Zdravlje glavnog čvora sustava za pohranu jedan je od glavnih zadataka SRE i operativnog tima. Implementacija orkestratora i HA rješenja temeljenog na VIP-u omogućila nam je postizanje sljedećih rezultata:

pouzdano otkrivanje problema s topologijom klastera baze podataka;
automatski i brzi odgovor na incidente povezane s masterom, smanjujući vrijeme prekida rada sustava.

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

skaliranje HA sheme na nekoliko podatkovnih centara zahtijevat će jednu L2 mrežu između njih;
Prije dodjele VIP-a na novom masteru, moramo ga osloboditi na starom. Proces je sekvencijalan, što povećava vrijeme oporavka;
otpuštanje VIP-a zahtijeva SSH pristup poslužitelju ili bilo koji drugi način pozivanja udaljenih procedura. Budući da poslužitelj ili baza podataka ima problema koji su uzrokovali proces oporavka, ne možemo biti sigurni da će uklanjanje VIP-a biti uspješno dovršeno. A to može dovesti do pojave dva poslužitelja s istom virtualnom IP adresom i problema split brain.

Izbjeći split brain, možete koristiti metodu KAMENI (“Shoot The Other Node In The Head”), koji u potpunosti izolira ili onesposobljava problematični čvor. Postoje i drugi načini implementacije visoke dostupnosti klastera: kombinacija VIP-a i DNS-a, usluge otkrivanja usluga i proxy usluge, sinkrona replikacija i druge metode koje imaju svoje nedostatke i prednosti.

Govorio sam o našem pristupu stvaranju MySQL failover klastera. Jednostavan je za implementaciju i pruža prihvatljivu razinu pouzdanosti u trenutnim uvjetima. Kako se cjelokupni sustav općenito, a posebno infrastruktura razvijaju, ovaj pristup će se nedvojbeno razvijati.

Izvor: www.habr.com

Orchestrator i VIP kao HA rješenje za MySQL klaster