Korištenje netransakcijskih tablica

Ako nema nikakvih prekida replikacije, tada replikacija bazirana na stanjima obično radi dobro s netransakcijskim tablicama. U suprotnom slučaju ako postoji greška u obnovi na netransakcijskoj tablici, kao kada je stanje prekinuto prije završetka, tada će „master“ i „slave“ serveri završiti s različitim podacima.
 
Za primjer, pretpostavimo obnovu na MyISAM tablici sa 100 redova. Ako stanja obnove 50 redova i tada ih netko zaustavi, što se dogodi? Pola redova će biti promijenjeno, a pola neće. Replikacija će sigurno izaći iz sinkronizacije, zato jer će se stanja ponovo izvršiti na „slave“ serveru i promijeniti svih 100 redova.
 
Ako se koriste MyISAM tablice, trebamo biti sigurni da je naredba “STOP SLAVE;“ pokrenuta prije zaustavljanja MySQL servera ili će gašenje uništiti svaki pokrenuti upit (uključujući bilo koje nezavršeno stanje obnove). Mehanizmi pohrane koji podržavaju transakcije nemaju ovaj problem. Ako se koriste transakcijske tablice, neuspješna obnova će biti prekinuta na „master“ serveru i neće biti zapisana u binarni dnevnik.
 
Miješanje transakcijskih i netransakcijskih tablica
Kada koristimo transakcijski mehanizam pohrane, tada MySQL ne sprema stanja koja su izvršena u binarni dnevnik sve dok se transakcija ne završi. Stoga, ako je transakcija prekinuta, MySQL neće zapisati stanja u dnevnik pa tako ta stanja neće biti replicirana na „slave“ server.
 
Kada se miješaju transakcijske i netransakcijske tablice, i dođe do prekida transakcije, MySQL će biti u mogućnosti prekinuti promjene na transakcijskim tablicama, ali netransakcijske tablice će biti trajno promijenjene isto kao kod obnove opisane u prošlom primjeru. Ako u transakciji nema slučaja prekinute obnove podataka, tada će se i na MyISAM mehanizmu pohrane podaci maknuti ako dođe do prekida transakcije. To se napravi zato što binarni dnevnik u tom slučaju zapisuje stanja koja su u transakciji i isto zapisuje „ROLLBACK“ tih stanja.
 
Sljedeći problem je kada se ne dogodi „deadlock“ (kada dva stanja čekaju jedno drugo na završetak) na „master“ serveru, a dogodi se na „slave“ serverima. Tablice koje koriste transakcijski mehanizam će moći napraviti „roll back“, a tablice s netransakcijskim mehanizmom neće.
 
U pravilu, trebalo bi se izbjegavati transakcije koje mijenjaju transakcijske i netransakcijske tablice. Ovo je naročito važno kada „slave“ server koristi netransakcijski mehanizam pohrane. Također bi se trebala izbjegavati sva stanja, a ne samo transakcije, koja miješaju transakcijske i netransakcijske tablice.
 
Nedeterministička stanja
Svako stanje koje mijenja podatke na nedeterministički način može uzrokovati različite podatke „slave“ servera od podataka na „master“ serveru. Na primjer, „UPDATE“ koji koristi „LIMIT“ i „WHERE“. Sve dok „WHERE“ usporedba ne daje iste rezultate, stanje može promijeniti različite redove na dva servera. Takav problem je rijedak, ali težak za otkriti pa se ne prakticira koristiti „LIMIT“ sa stanjima koja mijenjaju podatke.
 
Primjer takvih tablica se može naći u „INFORMATION_SCHEMA“ bazi podataka. One se mogu lako razlikovati između „master“ i „slave“ servera, pa rezultat isto može varirati. Konačno, treba biti svjestan da se mnoge varijable, kao što su „@@server_id“ i „@@hostname“, neće replicirati korektno prije MySQL 5.1 sustava. Kod replikacija baziranih na redovima nema ovih ograničenja.
 
Različiti mehanizmi pohrane na „master“ i „slave“ serverima
Često je praktično imati različite mehanizme pohrane na „slave“ serverima. U nekim okolnostima, replikacija bazirana na stanjima može producirati različite rezultate na „slave“ serverima s različitim mehanizmima pohrane. Na primjer, nedeterministička stanja češće uzrokuju probleme ako se mehanizam pohrane razlikuje na „slave“ serveru od mehanizma pohrane na „master“ serveru.
 
Ako smo otkrili podatke na „slave“ serveru koji su izvan sinkronizacije „master“ servera u specifičnim tablicama, potrebno je pregledati mehanizme pohrane koji se koriste na oba servera, isto kao i upite koji obnavljaju te tablice. Također su već opisani i problemi koji nastaju s transakcijama na različitim mehanizmima pohrane.

Podijelite članak:

Pretplatite se na naš newsletter