Nerepliciranje svih obnova

  • 6 min čitanja

Rating

Ako se zloupotrijebi „SET SQL_LOG_BIN=0“ ili se ne razumiju pravila filtra replikacije, „slave“ server možda neće izvršiti neke obnove koje su zauzele mjesto na „master“ serveru. Ponekad se ovo želi napraviti u svrhu arhiviranja., ali češće je slučajno i ima loše posljedice.   Na primjer, pretpostavimo da imamo pravilo „replicate_do_db“ za repliciranje samo „rep“ baze podataka na jednom od naših „slave“ servera. Ako se izvršavaju sljedeće naredbe na „master“ serveru, podaci „slave“ servera će postati drugačiji od „mastera“ servera:   mysql> USE test; mysql> UPDATE rep.tab ...   Drugi tipovi stanja mogu čak uzrokovati pad replikacije s greškom zbog zavisnosti o nerepliciranim podacima.  Sukob zaključavanja uzrokovan s InnoDB zaključavanjem „SELECT“-a InnoDB „SELECT“ stanje se normalno ne zaključava, ali u pojedinim slučajevima zahtjeva zaključavanje. Korištenjem „INSERT ... SELECT“ stanja se zaključavaju svi redovi koji se čitaju iz izvorne tablice. MySQL treba zaključavanje kako bi stanja osigurala iste podataka na „slave“ serveru kod izvršavanja. Sa zaključavanjem se stanja zapisuju serijski na „master“ serveru, što odgovara načinu kako će ih „slave“ server izvršiti.   Kada dođe do sukoba zaključavanja, blokiranja i prekida zaključavanja, tada je jedan od načina za smanjiti problem držati transakciju otvorenom samo koliko je to potrebno, pa tako zaključavanja uzrokuju manje blokiranja. Zaključavanja se mogu otpustiti sa izvršavanjem transakcije što prije je moguće na „master“ serveru.   Isto može pomoći korištenje stanja koja kratko traju, s razbijanjem velikih stanja u više manjih. To je vrlo efikasan način za reduciranje sukoba zaključavanja, i čak kad je teško za učiniti često je vrijedno.   Drugo zaobilaženje je zamjena „INSERT ... SELECT“ stanja s kombinacijom od „SELECT INTO OUTFILE“ popraćeno s „LOAD DATA INFILE“ na „master“ serveru. To je brzo i ne zahtjeva zaključavanje. Kod toga treba odabrati unikatno ime za izlaznu datoteku i obrisati izlaznu datoteku kada je više ne koristimo. Za dobivanje unikatnih imena se koristi tehnika s naredbom „CONNECTION_ID()“ koja je već spomenuta, a za čišćenje se koristiti periodični posao („crontab“ na Unix sustavu, a „scheduled task“ na Windows sustavu) za čišćenje nekorištenih datoteka nakon što je konekcija koja ih je kreirala završila s njima.   Možda ćemo biti u iskušenju onemogućiti zaključavanja umjesto korištenja ovih zaobilaznica. Postoji načina za učiniti to, ali nije dobra ideja za većinu scenarija, jer čini moguć izlazak „slave“ servera iz sinkronizacije s „master“ serverom. Isto čini binarni dnevnik nekorisnim za obnavljanje servera. Ako je ovaj rizik vrijedan dobitka, konfiguracijska promjena koja ostvaruje ovo je sljedeća: innodb_locks_unsafe_for_binlog = 1   Ovo dopušta stanjima zavisnost o podacima koji nisu zaključani. Ako jedno stanje modificira podatke i prihvati promjenu transakcije prije drugog stanja, tada ta dva stanja mogu zapisati različite podatke u binarni dnevnik. Ovaj slučaj se događa kod replikacije i obnove podataka.   Za prikaz kako zaključavanjem čitanja spriječiti kaos zamislimo da imamo dvije tablice. Prva bez redova, a druga s jednim redom koji ima vrijednost 99. Dvije transakcije obnavljaju podatke. Prva transakcija unosi sadržaj druge tablice u prvu tablicu, a druga transakcija obnavlja drugu (izvornu) tablicu, kako je prikazano na sljedećoj slici.   Upotreba zaključavanja kod transakcija Dok se unosio sadržaja iz druge tablice u prvu tablicu, transakcija je zaključala drugu tablicu s dijeljenim zaključavanjem (eng. shared lock). Zatim druga transakcija pokušava napraviti „UPDATE“ ali ne uspijeva jer dijeljeno zaključavanje omogućuje samo čitanje podataka sa zaključane tablice, a ne i promjenu podataka. Dalje kada se izvrši prva transakcija, tada se zapiše u binarni dnevnik i otključa se druga tablica. Sada druga transakcija može napraviti obnovu podataka, izvršiti se i zapisati se u binarni dnevnik. Transakcije su zapisane u dnevnik serijski kako su dolazile na sustava, što neće biti slučaj u sljedećem primjeru koji koristi opciju „innodb_locks_unsafe_for_binlog = 1“.   Upotreba transakcija bez zaključavanja tablica    U ovom slučaju prva transakcija je počela unositi podatke iz druge tablice u prvu tablicu i pri tome nije zaključala drugu tablicu. Prije nego se prva transakcija izvršila, druga transakcija na „master“ serveru je pokušala napraviti obnovu podataka druge tablice i uspjela, jer ta tablica nije zaključana. Pošto je transakcija uspješno završila ona se i zapisala u dnevnik. Nakon toga se izvrši prva transakcija i ona se isto zapiše u dnevnik. Sada su transakcije zapisane u drugačijem redoslijedu nego u prošlom primjeru, to će kasnije uzrokovati oštećenja podataka na „slave“ serveru. Umjesto što je prva tablica „slave“ servera prvo spremila vrijednost 99 pa se dogodila obnova druge tablice gdje ona prima vrijednost 99, sada se prvo napravila obnova pa je prva tablica primila vrijednost 100, a na „master“ serveru ima vrijednost 99.

STVORIMO NEŠTO NEVJEROJATNO ZAJEDNO!

Koliko je ovaj post bio koristan?

Kliknite na zvjezdicu da biste je ocijenili!

Prosječna ocjena / 5. Broj glasova:

Podijelite članak:

PRIJAVITE SE NA NAŠ Newsletter

Preporučeni