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… Pročitaj više

Zapisivanje na oba „master“ servera u „master-master“ replikaciji

Zapisivanje na oba „master“ servera uglavnom nije dobra ideja. Ako pokušavamo napraviti sigurno zapisivanje na oba „master“ servera u istom trenutku, tada mogu nastati mnogi problemi od kojih se ne mogu svi riješiti.   U MySQL 5.0 sustavu, dvije konfiguracijske varijable servera pomažu u rješavanju problema sukoba „AUTO_INCREMENT“ primarnih ključeva. Varijable su „auto_increment_increment“ i „auto_increment_offset“.   Ipak… Pročitaj više

Nerepliciranje svih obnova

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… Pročitaj više

Promjena podataka na „slave“ serveru

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“… Pročitaj više

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… Pročitaj više

Problemi i rješenja replikacije

MySQL replikacije se lako ruše. Jednostavna implementacija koja čini replikaciju jednostavnom za postavljanje, isto čini lakim zaustavljanje, zbunjivanje, ometanje i rušenje replikacije. U ovoj sekciji su opisani uobičajeni problemi, kako se oni prepoznaju i kako ih možemo riješiti.   Greške nastale oštećenjem ili gubitkom podataka   Iz različitih razloga, MySQL replikacija se ne može lako prilagoditi na… Pročitaj više

Promjena uloga u „master-master“ konfiguraciji

Jedna od prednosti „master¬master“ replikacije je što se pasivna i aktivna uloga mogu lako zamijeniti, zbog simetrične konfiguracije. U ovom pod¬poglavlju je pokazano kako napraviti zamjenu.   Kada se mijenjaju uloge u „master¬master“ konfiguraciji, najvažnija stvar je osigurati neka samo jedan od „master“ servera zapisuje trenutno. Ako se zapisivanje jednog „master“ servera isprepliće sa zapisivanjima drugog, zapisivanja… Pročitaj više

Neplanirano postavljanje

Ako se „master“ server sruši i trebamo mu postaviti za zamjenu „slave“ server, proces može biti vrlo kompliciran. Ako postoji samo jedan „slave“ server, jednostavno se koristi taj „slave“ server. Ali ako ima više od jednog „slave“ servera, trebat će se napraviti malo više koraka za postavljanje „slave“ servera za „master“ server.   Također postoji problem od… Pročitaj više

Promjena „master“ servera

Prije ili kasnije, trebat će postaviti „slave“ server na novi „master“ server. Možda se rotiraju serveri za nadogradnju, možda je došlo do greške i treba postaviti „slave“ server za „master“ server ili se samo premještaju kapaciteti. Bez obzira na ove razloge potrebno je informirati „slave“ server o novom „master“ serveru.   Kada je proces planiran lakše je… Pročitaj više

Ponovno sinkroniziranje „slave“ servera s „master“ serverom

Sigurno ćemo se više od jedanput sresti sa „slave“ serverima izvan sinkronizacije. Na primjer, pronalazak razlika na serverima nakon korištenja tehnike provjere. Možda je „slave“ server preskočio upit ili je netko mijenjao podatke na „slave“ serveru.   Tradicionalan način za rješavanje stanja izvan sinkronizacije je zaustavljanje i kloniranje s „master“ servera. Ako je nekonzistentan „slave“ server kritičan… Pročitaj više