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 rušenje sustava, gubitak struje, mrežne greške, oštećenja uzrokovana diskom ili memorijom. Gotovo sigurno će biti potrebno zaustaviti replikaciju na nekoj točci tijekom ovih grešaka. Većina grešaka nastaje nakon neočekivanog isključivanja replikacije gdje jedan od servera nije nešto osvježio na disku.
 
Neočekivano gašenje „master“ servera
Ako „master“ server nije konfiguriran sa „sync_binlog“, moguće je da nema osvježeno svojih nekoliko zadnjih događaja binarnog dnevnika na disku prije pada sustava. U/I dretva „slave“ servera može, zbog toga, biti u sredini čitanja pojedinog događaja koji nije nikada zapisan na disk. Kada se „master“ server ponovo pokrene, „slave“ server će napraviti konekciju i pokušati ponovo pročitati taj događaj, ali „master“ server će mu odgovoriti s porukom da nema toga događaja na disku.

 
Rješenje za ovaj problem je upućivanje „slave“ servera na čitanje s početka sljedećeg binarnog dnevnika. Ipak, neki događaji dnevnika će biti izgubljeni trajno, što bi trebalo biti spriječeno s konfiguriranjem „master“ servera sa „sync_binlog“. Iako smo konfigurirali „master“ server sa „sync_binlog“, tablice s MyISAM mehanizmom pohrane mogu i dalje postati oštećene kada se replikacija sruši (npr. kod korištenja transakcijskih i netransakcijskih tablica), isto tako tablice s InnoDB mehanizmom pohrane ako „innodb_flush_logs_at_trx_commit“ nije postavljen na 1.
 
Neočekivano gašenje „slave“ servera
Kada se „slave“ server ponovo pokrene nakon neplaniranog gašenja, on čita svoju „master.info“ datoteku kako bi odredio gdje je stao replicirati. Nažalost, ova datoteka nije sinkronizirana na disku, pa informacije koje sadrži mogu biti krive. „Slave“ server će vjerojatno probati ponoviti izvođenje nekoliko događaja binarnog dnevnika. Sve dok ne možemo odrediti gdje se „slave“ server stvarno zaustavio do tada nema drugog izbora nego preskočiti greške. „Maatkit“ alat pruža skriptu „mk¬slave¬restart“ koja može pomoći kod ovog problema.

 
Proces obnove InnoDB mehanizma pohrane ispisuje koordinate binarnog dnevnika do točke gdje je završena obnova, to se može koristit za upućivanje „slave“ servera na točku „master“ servera. Pogleda se u dnevnik grešaka MySQL¬a nakon ponovnog pokretanja „slave“ servera i nađu se koordinate. To vrijedi ako sve tablice koriste InnoDB mehanizam pohrane.
 
Oštećenje binarnog dnevnika na „master“ serveru
Ako je binarni dnevnik oštećen na „master“ serveru, nećemo imati drugog izbora nego pokušati preskočiti oštećenu poziciju. Pokretanjem naredbe „FLUSH LOGS“ na „master“ serveru se otvara nova datoteka binarnog dnevnika pa se „slave“ server usmjerava na početak novog binarnog dnevnika, ili se može pronaći završetak regija s greškom. Još jedan način je korištenje „SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1“ za preskakanje pojedinih oštećenih događaja. Ako postoji više od jednog oštećenog događaja, jednostavno se ponavlja proces sve dok svi ne budu preskočeni.

 
Oštećenja poveznih dnevnika na „slave“ serveru
Ako je binarni dnevnik „master“ servera neoštećen, tada se koristiti naredba „CHANGE MASTER TO“ za pokazivanje i ponovo dohvaćanje oštećenih poveznih dnevnika. Jednostavno se usmjerava „slave“ server na istu poziciju s koje trenutno replicira, za to se koriste naredbe „Relay_Master_Log_File“ i „Exec_Master_Log_Pos“. „Slave“ server će tada odbaciti povezne dnevnike i početi zapisivati u nove.

 
Binarni dnevnik izvan sinkronizacije transakcijskog dnevnika InnoDB mehanizma pohrane
Ako se „master“ server sruši, InnoDB mehanizam pohrane može spremiti transakciju kao izvršeni događaj čak iako nije zapisana u binarni dnevnik. Nema načina za obnovu izgubljene transakcije, sve dok nije u poveznom dnevniku „slave“ servera. To se može spriječiti sa „sync_binlog“ parametrom.

 
Obnove oštećenih binarnih dnevnika
Nažalost, MySQL ne može otkriti ovu vrstu oštećenja. To je razlog zašto je dobra ideja rutinski provjeravati je li „slave“ server ima dobre podatke.
 
Promijenjeni bajtovi i događaj je nevaljan SQL
Moguće je prikazati događaj s „mysqlbinlog“¬om i vidjeti neispravni podatak, kao sljedeći:
UPDATE tab SET col1??
Potrebno je pronaći početak sljedećeg događaja i usmjeriti čitanje na njega. Tako se može preskočiti taj nevaljan događaj.

 
Ispušteni bajtovi ili duljina događaja je pogrešna
U ovom slučaju, „mysqlbinlog“ će ponekada izaći s greškom ili će se srušiti jer ne može čitati događaje i ne može naći početak sljedećeg događaja.
 
Pojedini događaji su oštećeni, prepisani ili je pomak prebačen i sljedeći događaj počinje s krivim pomakom
Ponovo, „mysqlbinlog“ i u ovom slučaju ne može pomoći.

 
Kada je oštećenje jako veliko i „mysqlbinlog“ ne može više čitati događaje u dnevnicima, bit će potrebno preslaganje na heksadekadski ili neki drugi način za pronalaženje granica među događajima. Ovo obično nije teško za napraviti, zato jer oznake za raspoznavanje odvajaju događaje.
 
S malo pretraživanja, trebali bi biti u mogućnosti pronaći uzorak u svom binarnom dnevniku i odrediti sljedeći neoštećeni pomak događaja. Tada možemo pokušati preskočiti prošli nevaljali događaj(e) sa „–start¬position“ argumentom „mysqlbinlog“¬a, ili koristiti parametar u varijabli „MASTER_LOG_POS“ kod naredbe „CHANGE MASTER TO“.

Podijelite članak:

Pretplatite se na naš newsletter