Zdravo svima. Vladislav Rodin je u kontaktu. Trenutno predajem kurseve o arhitekturi softvera i arhitekturi softvera sa visokim stresom na OTUS-u. U iščekivanju početka novog toka kursa Odlučio sam da napišem kratak dio originalnog materijala koji želim podijeliti s vama.
Uvod
Zbog činjenice da HDD može izvesti samo oko 400-700 operacija u sekundi (što je neuporedivo sa tipičnim rps-om na sistemu visokog opterećenja), klasična disk baza predstavlja usko grlo arhitekture. Stoga je potrebno obratiti posebnu pažnju na obrasce skaliranja ovog skladišta.
Trenutno postoje 2 obrasca skaliranja baze podataka: replikacija i dijeljenje. Sharding vam omogućava da skalirate operaciju pisanja i, kao rezultat, smanjite broj okretaja po pisanju po serveru u vašem klasteru. Replikacija vam omogućava da uradite istu stvar, ali sa operacijama čitanja. Ovom obrascu je posvećen ovaj članak.
Replikacija
Ako pogledate replikaciju na veoma visokom nivou, to je jednostavna stvar: imali ste jedan server, na njemu su bili podaci, a onda ovaj server više nije mogao da se nosi sa opterećenjem čitanja ovih podataka. Dodajte još nekoliko servera, sinhronizujete podatke na svim serverima i korisnik može čitati sa bilo kog servera u vašem klasteru.
Unatoč svojoj prividnoj jednostavnosti, postoji nekoliko opcija za klasifikaciju različitih implementacija ove sheme:
- Po ulogama u klasteru (master-master ili master-slave)
- Prema poslanim objektima (zasnovano na redovima, na temelju iskaza ili mješovito)
- Prema mehanizmu sinhronizacije čvora
Danas ćemo se pozabaviti tačkom 3.
Kako nastaje urezivanje transakcije?
Ova tema nije direktno povezana s replikacijom, o njoj se može napisati poseban članak, ali budući da je dalje čitanje beskorisno bez razumijevanja mehanizma urezivanja transakcije, da vas podsjetim na najosnovnije stvari. Obaveza transakcije se odvija u 3 faze:
- Zapisivanje transakcije u dnevnik baze podataka.
- Korištenje transakcije u mašini baze podataka.
- Vraćanje potvrde klijentu da je transakcija uspješno primijenjena.
U različitim bazama podataka ovaj algoritam može imati nijanse: na primjer, u InnoDB mašini MySQL baze podataka postoje 2 dnevnika: jedan za replikaciju (binarni dnevnik), a drugi za održavanje ACID-a (poništi/redo dnevnik), dok u PostgreSQL-u postoji jedan dnevnik koji obavlja obje funkcije (napišite unaprijed log = WAL). Ali ono što je gore predstavljeno je upravo opći koncept, koji dozvoljava da se takve nijanse ne uzimaju u obzir.
Sinhrona (sinhronizirana) replikacija
Dodajmo logiku za repliciranje primljenih promjena u algoritam urezivanja transakcije:
- Zapisivanje transakcije u dnevnik baze podataka.
- Korištenje transakcije u mašini baze podataka.
- Slanje podataka svim replikama.
- Primanje potvrde od svih replika da je transakcija na njima završena.
- Vraćanje potvrde klijentu da je transakcija uspješno primijenjena.
Ovakvim pristupom imamo niz nedostataka:
- klijent čeka da se promjene primjene na sve replike.
- kako se broj čvorova u klasteru povećava, smanjujemo vjerovatnoću da će operacija pisanja biti uspješna.
Ako je sve manje-više jasno sa 1. tačkom, onda su razlozi za 2. tačku vrijedni objašnjenja. Ako tokom sinhrone replikacije ne dobijemo odgovor od barem jednog čvora, vraćamo transakciju. Dakle, povećanjem broja čvorova u klasteru, povećavate vjerovatnoću da operacija pisanja neće uspjeti.
Možemo li čekati potvrdu samo od određenog procenta čvorova, na primjer, od 51% (kvorum)? Da, možemo, ali u klasičnoj verziji potrebna je potvrda sa svih čvorova, jer na taj način možemo osigurati potpunu konzistentnost podataka u klasteru, što je nesumnjiva prednost ove vrste replikacije.
Asinhrona (asinhronizirana) replikacija
Izmijenimo prethodni algoritam. Podatke ćemo poslati replikama "nekad kasnije", a "nekad kasnije" promjene će se primijeniti na replike:
- Zapisivanje transakcije u dnevnik baze podataka.
- Korištenje transakcije u mašini baze podataka.
- Vraćanje potvrde klijentu da je transakcija uspješno primijenjena.
- Slanje podataka u replike i primjena promjena na njih.
Ovakav pristup dovodi do činjenice da klaster radi brzo, jer ne čekamo klijenta da podaci stignu do replika, pa čak i da budu predani.
Ali uvjet dampinga podataka na replike “nekad kasnije” može dovesti do gubitka transakcije, te do gubitka transakcije koju je korisnik potvrdio, jer ako podaci nisu imali vremena da se repliciraju, potvrda klijentu o uspješnosti operacije je poslano, a čvor na koji su promjene stigle srušio se HDD, gubimo transakciju, što može dovesti do vrlo neugodnih posljedica.
Semisync replikacija
Konačno dolazimo do polusinhrone replikacije. Ova vrsta replikacije nije previše poznata ili vrlo česta, ali je od velikog interesa jer može kombinovati prednosti i sinhrone i asinhrone replikacije.
Pokušajmo kombinirati prethodna 2 pristupa. Nećemo dugo zadržati klijenta, ali ćemo zahtijevati da se podaci repliciraju:
- Zapisivanje transakcije u dnevnik baze podataka.
- Korištenje transakcije u mašini baze podataka.
- Slanje podataka u replike.
- Primanje potvrde od replike da su promjene primljene (biti će primijenjene “nekad kasnije”).
- Vraćanje potvrde klijentu da je transakcija uspješno primijenjena.
Imajte na umu da s ovim algoritmom, gubitak transakcije nastaje samo ako i čvor koji prima promjene i čvor replike ne uspiju. Vjerovatnoća takvog kvara smatra se malom i ovi rizici se prihvataju.
Ali s ovim pristupom postoji mogući rizik od fantomskog čitanja. Zamislimo sljedeći scenario: u koraku 4, nismo primili potvrdu ni od jedne replike. Moramo vratiti ovu transakciju i ne vraćati potvrdu klijentu. Budući da su podaci primijenjeni u koraku 2, postoji vremenski razmak između kraja koraka 2 i vraćanja transakcije unatrag, tokom kojeg paralelne transakcije mogu vidjeti promjene koje ne bi trebale biti u bazi podataka.
Polusinhronizirana replikacija bez gubitaka
Ako malo razmislite, možete samo obrnuti korake algoritma i riješiti problem fantomskog čitanja u ovom scenariju:
- Zapisivanje transakcije u dnevnik baze podataka.
- Slanje replika podataka.
- Primanje potvrde od replike da su promjene primljene (biti će primijenjene “nekad kasnije”).
- Korištenje transakcije u mašini baze podataka.
- Vraćanje potvrde klijentu da je transakcija uspješno primijenjena.
Sada unosimo promjene samo ako su replicirane.
zaključak
Kao i uvijek, ne postoje idealna rješenja, postoji skup rješenja, od kojih svako ima svoje prednosti i nedostatke i pogodno je za rješavanje različitih klasa problema. Ovo je apsolutno tačno za odabir mehanizma za sinhronizaciju podataka u repliciranoj bazi podataka. Skup prednosti koje polusinhrona replikacija ima dovoljno je solidan i zanimljiv da se može smatrati vrijednim pažnje, uprkos niskoj rasprostranjenosti.
To je sve. Vidimo se na !
izvor: www.habr.com