Promjena podataka na „slave“ serveru

  • 6 min čitanja

Rating

Replikacija bazirana na stanjima, za ispravno izvršavanje, treba imati iste podatke na „slave“ serveru kakvi su oni na „master“ serveru, zato ne bi trebali dopustiti nikakve promjene na „slave“ serveru (korištenjem „read_only“ konfiguracijske opcije to se lako postiže). Razmotrimo sljedeće stanje: mysql> INSERT INTO tablica1 SELECT * FROM tablica2; Ako tablica „tablica2“ sadrži različite podatke na „slave“ serveru, tada će tablica „tablica1“ isto završiti s različitim podacima. Drugim riječima, različiti podaci su skloni rasprostranjivati se s tablice na tablicu. Ovo se događa sa svim tipovima upita, ne samo INSERT ... SELECT upitima. Postoje dva moguća ishoda, dobit će se greška kao što je prijestup s dupliciranjem indeksa na „slave“ serveru ili se uopće neće dobiti nikakva greška. Dobivanje greške je dobro jer nas barem upozorava da podaci nisu isti na „slave“ serveru. Ovaj problem se može riješiti samo s ponovnom sinkronizacijom podataka s „master“ servera.  Nejedinstveni ID-ovi servera Ovo je jedan od najgorih problema s kojim se možemo sresti kod replikacije. Ako slučajno konfiguriramo dva „slave“ servera s istim ID¬em, može se činiti da sve radi dobro ako pažljivo ne gledamo, ali ako gledamo dnevnik grešaka ili promatramo „master“ server s „innotop“ (alat za praćenje rada MySQL sustava), primijetiti ćemo nešto jako čudno.   Na „master“ serveru ćemo vidjeti samo jedan od dva „slave“ servera s konekcijom u bilo kojem trenutku (obično, svi „slave“ serveri imaju konekciju i repliciraju cjelo vrijeme). Na „slave“ serveru ćemo vidjeti frekventno prekidanje i uspostavljanje konekcije zapisano u dnevniku grešaka, ali ne i grešku o krivo konfiguriranom ID¬u.   Ovisno o MySQL verziji, „slave“ server može činiti replikaciju ispravno ali sporo, ili je moguće neispravno repliciranje, tj. svaki „slave“ server može promašiti događaj binarnog dnevnik ili čak ponoviti ga, uzrokovati dupliciranje ključa i slično. Isto se mogu oštetiti podaci na „master“ serveru zbog povećanog učitavanja sa servera koji je zapeo u repliciranju vlastitih događaja. I kada su serveri međusobno u sukobu, dnevnik grešaka može ogromno narasti u jako malom vremenu.   Jedina solucija za ovaj problem je oprez kod postavljanja ID¬ova „slave“ servera. Za to si je korisno napraviti mapu gdje su zapisani ID¬ovi svih servera.  Nedefinirani ID¬ovi servera  Ako ne definiramo ID servera u „my.ini“ datoteci, činiti će se da je replikacija postavljena s naredbom „CHANGE MASTER TO“, ali neće se dopustiti pokretanje „slave“ servera:   mysql> START SLAVE; ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO   Ova greška može osobito zbunjivati ako smo baš koristili naredbu „CHANGE MASTER TO“ i provjerili svoje postavke s naredbom „SHOW SLAVE STATUSG“. Možemo dobiti vrijednosti sa „SELECT @@server_id“, ali to su uobičajene postavljene vrijednosti. Potrebno je vrijednosti postaviti eksplicitno.  Ovisnost o nerepliciranim podacima Ako imamo baze podataka ili tablice na „master“ serveru koje ne postoje na „slave“ serveru, vrlo je jednostavno slučajno srušiti replikaciju. Pretpostavimo da postoji baza podataka na „master“ serveru koja ne postoji na „slave“ serveru. Ako se dogodi bilo koja obnova podataka na „master“ serveru replikacija će se srušiti kad će „slave“ server pokušati replicirati.   Nema rješenja za ovaj problem. Jedini način kako to možemo spriječiti je izbjeći kreiranje tablica na „master“ serveru koje neće postojati na „slave“ serveru.   Kako se kreiraju takve tablice? Postoji mnogo načina, neke je teže spriječiti od drugih. Na primjer, pretpostavimo bazu podataka na „slave“ serveru koja nije kreirana na „master“ serveru i tada iz nekog razloga zamijenimo uloge „master“ i „slave“ servera. Kada smo to napravili, možda smo zaboravili maknuti tu bazu podataka i njene privilegije. Sada se netko može spojiti na novi „master“ i pokrenuti upit u toj bazi podataka, ili periodični posao može otkriti tablice i pokrenuti „OPTIMIZE TABLE“ na svakoj od njih. To će dovesti do raznih problema.   Ovo je jedna od stvari koje treba imati na umu kada promoviramo „slave“ server za „master“ server ili kada odlučujemo kako konfigurirati „slave“ servere. Sve što čini „slave“ server drugačije od „master“ servera, ili obratno, može biti potencijalni problem u budućnosti.  Nedostajanje temporalne tablice Temporalne tablice su praktične za neke upotrebe, ali nažalost nekompatibilne su s replikacijama baziranim na stanjima. Ako se „slave“ server sruši, ili ako ga isključimo, svaka temporalna tablica koju je koristila dretva „slave“ servera će nestati. Kada se ponovo pokrene „slave“ server, svako daljnje stanje koje se referencira na nedostajuću temporalnu tablicu će se srušiti   Nema sigurnog načina za korištenje temporalnih tablica na „master“ serveru s replikacijom baziranom na stanjima. Nije važno koliko postoje, temporalne tablice čine nemogućim zaustavljanje, pokretanje i obnovu nakon pada sustava. Ovo je istinito iako se koriste unutar samo jedne transakcije. (Manji je problem ako se koriste na „slave“ serverima koji ne postaju „master“ serveri.)   Ako se replikacija zaustavi jer „slave“ server ne može naći tablicu nakon ponovnog pokretanja, postoji samo nekoliko stvari za napraviti. Greške koje su se dogodile mogu se preskočiti ili se može ručno kreirati tablica koja ima isto ime i strukturu kao trenutno nestala temporalna tablica. S bilo kojim od tih načina podaci će vjerojatno biti drugačiji na „slave“ serveru ako se bilo koji upit zapisivanja referencira na temporalnu tablicu.   Nije tako teško kako se čini eliminirati temporalne tablice. Dvije najkorisnije postavke temporalnih tablica su sljedeće:   ¬One su vidljive samo konekciji koja ih kreira, pa zato nisu u konfliktu s ostalim konekcijama temporalnih tablica istih imena. ¬One odlaze kada se konekcija zatvori, pa ih zato nije potrebno micati eksplicitno.   Ove postavke se mogu lako oponašati s rezerviranjem baze podataka eksplicitno za pseudo¬temporalne tablice, gdje će se umjesto temporalnih tablica kreirati trajne tablice. Potrebno je samo odabrati unikatna imena za njih. Na sreću to je vrlo jednostavno za napraviti: jednostavno se doda ID konekcije na ime tablice. Na primjer, gdje se izvršava „CREATE TEMPORARY TABLE top_users(...)“, sada se može izvršiti „CREATE TABLE temp.top_users_1234(...)“, gdje je 1234 vrijednost vraćena s „CONNECTION _ID()“. Nakon što je aplikacija završila sa pseudo¬temporalnom tablicom, možemo je obrisati ili dopustiti procesu čišćenja da je makne umjesto nas. Posjedovanje ID¬a konekcije u imenu tablice čini jednostavnim za odrediti koja tablica više nije u upotrebi. Popis aktivnih konekcija se može dobiti sa „SHOW PROCESSLIST“ i tada se usporede ID¬ovi konekcija s imenima tablica. („mk_find“, skripta od „Maatkit“¬a, može maknuti pseudo¬temporalne tablice jednostavno s „–pid“ i „–sid“ opcijom.)   Korištenje pravih tablica umjesto temporalnih tablica ima i druge prednosti. Na primjer, pomoću njih se lakše napravi „debug“ naših aplikacija, zato jer se može vidjeti podatke kojima aplikacija manipulira s druge konekcije. Ako se koristi temporalna tablica, to neće biti tako lako za učiniti.   S pravim tablicama ima više upravljanja nego s temporalnih tablica; sporije je kreiranje pravih tablica zato jer „.frm“ datoteka povezana s tablicama mora biti sinkronizirana s diskom. Ako se onemogući opcija „sync_frm“ tada se rad ubrza, ali sigurnost je manja.   Ako se koriste temporalne tablice, trebalo bi sigurno postaviti statusnu varijablu „Slave_open_temp_tables“ na vrijednost 0 prije isključivanja „slave“ servera. Ako nije 0, može doći do problema s ponovnim pokretanjem „slave“ servera. Svojstvena procedura je pokretanje naredbe „STOP SLAVE;“, pregled varijable, i samo tada isključivanje „slave“ servera. Ako se isključi „slave“ server prije pregleda varijable, tada se kod ponovnog pokretanja riskira s redoslijedom otvaranja tablica.

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