Neplanirano postavljanje

  • 6 min čitanja

Rating

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 potencijalnog gubljenja replikacijskih događaja. Postoji mogućnost kada neke obnove koje su se dogodile na „master“ serveru još nisu replicirane na njegove „slave“ servere. Čak je i moguće kada je stanje izvršeno i tada napravljen „roll back“ na „master“ serveru, ali nije napravljen „roll back“ na „slave“ serveru, pa će ustvari „slave“ server biti ispred logičke pozicije replikacije „master“ servera (ovo je moguće samo ako se miješaju transakcijske i netransakcijske tablice). Ako se mogu obnoviti podaci „master“ servera u nekoj točci, bit će moguće napraviti povrat izgubljenih stanja i izvršiti ih ručno.   U svim od sljedećih koraka, treba biti siguran da se u računicama koriste ispravne „Master_Log_File“ i „Read_Master_Log_Pos“ vrijednosti. Ovo je procedura za postavljanje „slave“ servera u „master¬slave“ topologiji:   I) Treba odrediti koji „slave“ server ima najnovije podatke. Provjeriti rezultat s „SHOW SLAVE STATUSG“ na svakom „slave“ serveru i izabrati onoga čije „Master_Log_File“ i „Read_Master_Log_Pos“ koordinate su najnovije.   II) Pustiti neka svi „slave“ serveri završe izvršavanje poveznih dnevnika koje su dohvatili sa starog „master“ servera prije njegovog pada. Ako se promjeni „master“ server od „slave“ servera prije nego se izvrše promjene poveznog dnevnika, „slave“ server će odbaciti ostale događaje dnevnika i neće se znati gdje je zaustavljen.   III) Uvažiti korake od 5¬7 iz prošle postavke.   IV)Usporediti svakom „slave“ serveru „Master_Log_File“ i „Read_Master_Log_Pos“ koordinate s onima na „master“ serveru.   V) Uvažiti korake 10¬12 s liste u prošloj postavci.   Pretpostavimo da imamo „log_bin“ i „log_slave_update“ omogućeno na svim „slave“ serverima. Omogućivanje ovih praćenja dnevnika omogućuje obnovu svih „slave“ servera na konzistentnu točku u vremenu, što se ne može pouzdano napraviti na drugačiji način.  Pronalaženje željene pozicije dnevnika Ako svaki „slave“ server nije na istoj poziciji kao novi „master“ server, bit će potrebno pronaći poziciju u novom binarnom dnevniku „master“ servera koja odgovara zadnjem događaju kojeg je „slave“ server replicirao, i koristiti tu poziciju za „CHANGE MASTER TO“. Može se koristiti alat „mysqlbinlog“ za otkrivanje zadnjeg upita kojeg je „slave“ server izvršio i pronalaženje tog istog upita u novom binarnom dnevniku „master“ servera.   Za prikazivanje ovoga, pretpostavimo neka događaji dnevnika imaju automatski povećavajući ID broj i neka je „slave“ server s najnovijim podacima (novi „master“ server) upravo prihvatio događaj 100 kada se stari „master“ server srušio. Sada pretpostavimo neka postoje još dva „slave“ servera, „server2“ i „server3“; „server2“ server je prihvatio događaj 99, a „server3“ server je prihvatio događaj 98. Ako se oba „slave“ servera usmjere na trenutnu poziciju binarnog dnevnika novog „master“ servera, oni će početi replicirati događaj 101, pa će tako oni biti izvan sinkronizacije. Tako dugo dok je novi binarni dnevnik „master“ servera omogućen s „log_slave_updates“, može se pronaći događaj 99 i 100 u binarnom dnevniku novog „master“ servera, pa se tako „slave“ serveri mogu dovesti u konzistentno stanje.   Zbog ponovnog pokretanja servera, različite konfiguracije, rotacije dnevnika ili „FLUSH LOGS“ naredbe (zatvara i otvara sve dnevnike, ako je omogućeno zapisivanje u binarni dnevnik, tada otvara novu datoteku binarnog dnevnika), isti događaji mogu postajati na različitim bajtovima pomaka na različitim serverima. Pronalaženje događaja može biti sporo i dosadno, ali obično nije teško. Samo se prikaže zadnji događaj na svakom „slave“ serveru s „mysqlbinlog“ alatom na binarnom ili poveznom dnevniku „slave“ servera. Tada se pronađe isti upit u binarnom dnevniku novog „master“ servera, isto s „mysqlbinlog“ alatom. To će prikazati pomak u bajtovima od upita, i taj pomak se može koristiti u „CHANGE MASTER TO“ naredbi prilikom postavljanja svakom „slave“ serveru novog „master“ servera.   Proces se može učiniti bržim s oduzimanjem bajtova pomaka na kojima su se novi „master“ i „slave“ serveri zaustavili, što nam govori o razlici njihovih pozicija. Ako se tada ta vrijednost oduzme od pozicije binarnog dnevnika novog „master“ servera, postoje šanse za pronalazak traženog upita na toj poziciji. Samo treba provjeriti je li tako, i pronašli smo poziciju na kojoj je potrebno pokrenuti „slave“ server.   Pogledajmo konkretan primjer. Pretpostavimo kako je „server1“ „master“ server od „server2“ i „server3“ servera, i on padne. Što se tiče „Master_Log_File“ i „Read_Master_Log_Pos“ u „SHOW SLAVE STATUSG“ naredbi, „server2“ server je napravio repliciranje svih događaja koji su bili u binarnom dnevniku od servera „server1“, ali „server3“ server nema najnovije podatke. Sljedeća slika prikazuje ovaj scenarij.    Kao što slika prikazuje, mi možemo biti sigurni da je „server2“ server replicirao sve događaje iz binarnog dnevnika „master“ servera zato jer „Master_Log_File“ i „Read_Master_Log_Pos“ pokazuju zadnju poziciju servera „server1“. Stoga, možemo postaviti „server2“ server za novi „master“ server, a „server3“ server mu postaviti za „slave“ server.   Ali koje parametre ćemo trebati koristiti u naredbi „CHANGE MASTERT TO“ na serveru „srever3“? To je mjesto gdje trebamo napraviti malo matematičkog računanja i istraživanja. „Server3“ server je zaustavljen na pomaku 1493, što je 89 bajtova iza 1582, zadnje izvršene naredbe od servera „servera2“. „Server2“ server trenutno zapisuje na poziciju 8167 u svojem binarnom dnevniku. 8167¬89=8078, pa ustvari trebamo usmjeriti „server3“ server na pomak dnevnika servera „servera2“ (8078). Dobra je ideja istražiti dnevnike događaja oko ove pozicije i uvjeriti se u ispravnost rezultata servera „server2“ na tom pomaku u vlastitim dnevnicima. Ipak, može tamo biti nešto drugo zbog obnove podataka koje su se dogodili samo na serveru „server2“.   Pretpostavimo da su događaji isti kao na slici i u opisanom primjeru, sljedeća naredba će promijeniti server „server3“ u „slave“ server „servera2“ servera:   server2> CHANGE MASTER TO MASTER_HOST="server2", MASTER_LOG_FILE="mysql-bin.000009",   MASTER_LOG_POS=8078;   Što ako je server „server1“ ustvari završio izvršavanje i zapisivanje u dnevnik još jednog događaja, iza pomaka 1582, kada se srušio? Zato jer je server „server2“ čitao i izvršio samo iznad pomaka 1582, jedan događaj će biti zauvijek izgubljen. Ako disk starog „master“ servera nije oštećen, i dalje se mogu obnoviti nedostajući događaji sa njegovog binarnog dnevnika s „mysqlbinlog“ ili s dnevničkim serverom.   Ako je potrebno obnoviti nedostajuće događaje sa starog „master“ servera, preporuča se to napraviti nakon postavljanja novog „master“ servera, ali prije nego što se klijenti spoje na njega. Zato jer, ne želimo izvršavati nedostajuće događaje na svakom „slave“ serveru. Bolje je ako to replikacija napravi umjesto nas. Ako je „master“ server totalno nedostupan, taj posao se može obaviti kasnije.

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