Zapisivanje na oba „master“ servera u „master-master“ replikaciji 2. dio

Najbolje korištenje pričuvne memorije za dretvu „slave“ servera

Ako imamo određeni tip učitavanja, tada možemo prethodno dohvatiti podatke u memoriju i tako ubrzati replikaciju. Ideja je korištenje programa koji čita malo ispred SQL dretve „slave“ servera u poveznom dnevniku i izvršava upite. To radi tako što se sljedeći upit iz dnevnika izvršava kao „SELECT“ stanje. Tako server dohvaća neke podataka s diska u memoriju prije izvršavanja pa kada SQL dretva „slave“ servera izvršava stanja iz poveznog dnevnika, tada ne mora čekati dohvaćanje podataka s diska.

Koliko daleko ispred od SQL dretve „slave“ servera bi program trebao stati s izvođenjem upita unaprijed može varirati. Možda nekoliko sekunda ili ekvivalentan broj bajtova u poveznom dnevniku. Ako se otiđe predaleko naprijed, podaci koji se dohvaćaju u pričuvnu memoriju će biti osvježeni i ponovo možda neće biti od koristi.

Pogledajmo primjer kako prepisati stanja za dobivanje prednosti od ovog pristupa. Razmotrimo sljedeći upit:

mysql> UPDATE zabava.film SET trajanje=4 WHERE film_id=123;
Sljedeći SELECT vraća iste redove i kolone:
mysql> SELECT trajanje FROM zabava.film WHERE film_id=123;
Ova tehnika neće raditi sve dok nemamo ispravne karakteristike učitavanja i ispravnu hardversku konfiguraciju. Sljedeće okolnosti mogu odrediti hoće li to raditi:

¬SQL dretva „slave“ servera može raditi samo s jednim podacima u jednom trenutku.
Ako server ima više tvrdih diskova tada on nema to ograničenje rada s jednim
podacima i može napraviti paralelno dohvaćanje podataka unaprijed.
-Radni skup je mnogo veći od memorije (što je razlog zašto SQL dretva „slave“ servera troši puno vremena na čekanje U/I operacija). Ako je radni skup već smješten u memoriji, tada dohvaćanje unaprijed neće pomoći.

„Slave“ serveri obično koriste više diskova. Česta upotreba je osam ili više diskova po „slave“ serveru. Može funkcionirati i s manje, ali preporuča se najmanje između dva do četiri.

-Koristi se mehanizam pohrane sa zaključavanjem na razini retka, kao što je InnoDB. Pokušavanjem ovoga na MyISAM tablicama će vjerojatno dovesti do sukoba. Sukobit će se zaključane tablice sa SQL dretvom „slave“ servera i dretvama koje dohvaćaju unaprijed, to usporava stvari još više (ako imamo mnogo tablica i zapisivanja su raspodijeljena među njima, u teoriji, ima čak mogućnost za ubrzavanje replikacije na MyISAM tablicama korištenjem ove tehnike).

Stanja koja profitiraju iz ovog pristupa su „UPDATE“ i „DELATE“. „INSERT“ stanja manje profitiraju iz ovog pristupa, pogotovo kad su redovi umetnuti slijedno, zato što je kraj indeksa već poznat iz prošlog unosa.

Ako tablica ima mnogo indeksa, možda se neće moći dohvatiti unaprijed sve podatke koje stanje modificira. „UPDATE“ stanje može modificirati svaki indeks, ali „SELECT“ će tipično čitati primarni ključ i jedan sekundarni indeks, u najboljem slučaju. „UPDATE“ će i dalje trebati dohvaćati ostale indekse za modifikaciju. To smanjuje efekt ove taktike na tablicama s mnogo indeksa.

Ova tehnika neće uvijek donositi profit. Postoji mnogo razloga zašto to možda neće raditi ili će uzrokovati probleme. Trebalo bi samo pokušavati ako dobro poznamo hardver i operacijski sustav. Postoje slučajevi gdje je ova tehnika ubrzala replikacije od 300 – 400%, ali to ne znači da će uvijek ispravno raditi. Važno je dobivanje ispravnih parametara, ali ne postoji niti uvijek ispravna kombinacija parametara. Ponekad datotečni sustav ili/i ponašanje jezgre može dovesti do neučinkovitosti. (Alat „mk¬slave¬prefetch“ od „Maatkit“¬a primjenjuje takvu implementaciju.)

Preveliki paketi s „master“ servera
Drugi problem koji je teško pratiti u replikaciji se može dogoditi kada „master“ server ima postavljenu opciju „max_allowed_packet“ različito od „slave“ servera. U tom slučaju, „master“ server može zapisati pakete koje „slave“ server shvaća prevelikima i kada „slave“ server dobije događaj binarnog dnevnika, tada može doći do raznih problema. To uključuje beskonačnu petlju pogrešaka i pokušaja, oštećenje u poveznom dnevniku i slično.

Ograničena propusnost komunikacijskog kanala
Ako se replicira na ograničenoj propusnosti komunikacijskog kanala, tada se postavi „slave_compressed_protocol“ opcija na „slave“ serveru (omogućena od verzije MySQL 4.0). Kada se „slave“ server spoji na „master“ server, zahtijevati će konekciju s kompresijom, istu kompresiju koju može koristiti svaki MySQL klijent. Mehanizam korišten za kompresiju je „zlib“. Testom je dokazano da se tekstualni podaci mogu smanji grubo rečeno na trećinu. Cijena toga je što je potrebno dodatno vrijeme za kompresiju na „master“ serveru i dekompresiju na „slave“ serveru.

Ako imamo slabu vezu s „master“ serverom na jednoj strani i mnogo „slave“ servera na drugoj strani, tada je dobro koristiti distribucijski „master“ server i na njega povezati „slave“ servere. Tako se samo jedan server spaja na „master“ server preko spore veze.

Nedostatak prostora na disku
Replikacija isto može popuniti disk s binarnim dnevnicima, poveznim dnevnicima ili temporalnim podacima, pogotovo ako se radi mnogo „LOAD DATA INFILE“ upita na „master“ serveru i ima postavljena opcija „log_slave_updates“ na „slave“ serveru. Što više „slave“ serveri zaostaju, više prostora diska se koristi za povezne dnevnike koji su dohvaćeni s „master“ servera, ali nisu izvršeni. Ovo se može spriječiti s praćenjem korištenja diska i postavljanjem „relay_log_space“ konfiguracijske varijable.

Ograničenja replikacije
MySQL replikacija se može srušiti ili izaći iz sinkronizacije, s ili bez grešaka, samo zbog svojih ograničenja. Veliki popis SQL funkcija i programskih zahtjeva se neće replicirati pouzdano (mnogi problemi su već spomenuti). Teško je reći da se neki od ovih problema neće dogoditi u našoj aplikaciji.

Druga stvar su greške na serveru. Mnoge vodeće verzije MySQL servera u prošlosti su imale greške s replikacijom, pogotovo u prvim izdanjima vodeće verzije. Nove mogućnosti kao što su pohranjene procedure obično uzrokuju mnogo problema.

Za mnoge korisnike ovo nije razlog za izbjegavanje novih mogućnosti. Samo je razlog za pažljivo testiranje, pogotovo kada se nadograđuju aplikacije ili MySQL sustav. Praćenje je isto važno; potrebno je znati kada nešto uzrokuje problem.

MySQL replikacija je komplicirana, i što su više aplikacije komplicirane, treba biti sve više oprezan. Ipak, ako se nauči kako upravljati s replikacijom, tada ona radi dobro.

Podijelite članak:

Pretplatite se na naš newsletter