InnoDB iš Vidaus: ibdata1 ir Log Failai

ibdata1 failas yra vienas pačių svarbiausių failų visoje InnoDB infrastruktūroje. Be šio failo InnoDB tiesiog negalėtų funkcionuoti – šiame įraše panagrinėsime kodėl.

Kas yra ibdata1 ir Kodėl Šis Failas Toks Svarbus?

ibdata1 failas yra visos InnoDB infrastruktūros lentelių erdvė – šiame faile yra gyvybiškai svarbi informacija InnoDB varikliui. Štai kaip atrodo InnoDB infrastruktūra (atkreipkite dėmesį į ibdata1 vietą dešinėje):

ibdata1 faile yra kelios informacijos klasės, kurios yra būtinos norint palaikyti InnoDB veikimą.

Kas yra Faile ibdata1?

Deja, MySQL pagal nutylėjimą neteikia informacijos apie tai, kas saugoma ibdata1 faile, tačiau mes žinome tam tikrus dalykus. Šiame faile yra:

• Lentelių duomenų puslapiai;
• Lentelių indeksų puslapiai;
• Duomenų žodynas;
• Multiversioning Concurrency Control (MVCC) duomenys;
• Anuliuotos erdvės (undo space);
• Atstatymo segmentai;
• Dvigubo rašymo (double write) buferis;
• Įrašų (insert) buferis.

Štai ką visa tai reiškia:

• Puslapis yra fiksuoto dydžio duomenų saugykla;
• InnoDB duomenų žodyną sudaro vidinės sistemos lentelės, skirtos sekti objektus (lenteles, indeksus ir lentelių stulpelius);
• MVCC užtikrina, kad jei kas nors skaito iš duomenų bazės tuo metu, kai kažkas į ją rašo, vis tiek bus matomi nuoseklūs duomenys. Šis metodas dažniausiai naudojamas duomenų bazių valdymo sistemose tam, kad būtų užtikrinta prieiga prie duomenų bazės;
• Anuliavimų žurnalas (“undo log”) yra anuliuotų log įrašų rinkinys – anuliuotuose log įrašuose yra informacijos apie tai, kaip anuliuoti paskutinį pakitimą į indekso įrašą;
• Atšaukiami (“rollback”) segmentai yra duomenų bazės objektai, naudojami anuliuotai informacijai sekti;
• Dvigubo rašymo buferio (“double write buffer”) tikslas yra užkirsti kelią duomenų sugadinimui iš dalinų įrašų į puslapius;
• InnoDB įrašų buferis yra standartinė InnoDB funkcija – variklis naudoja šią funkciją tam, kad atnaujinimai būtų atlikti vienu metu, o ne atskirai.

Darbas su ibdata1 – Konfigūracija

Jei kada dirbote su MySQL, turbūt pastebėjote, kad ibdata1 failas auga tada, kai įrašote duomenis į lentelę, turinčią InnoDB variklį. Taip pat galėjote pastebėti, kad MySQL nepateikia paprastų būdų kaip sumažinti šio failo dydį – taip yra todėl, nes ibdata1 failo negalima sumažinti, nebent ištrinsite visas duomenų bazes, neištrinsite su InnoDB susijusių failų ir iš naujo nepaleisite MySQL.

Norėdami sumažinti ibdata1 dydį, atlikite šiuos veiksmus:

1. Pasiimkite MySQL duomenų atsarginę kopiją;
2. Pašalinkite visas duomenų bazes išskyrus mysql ir performance_schema duomenų bazes;
3. Sustabdykite MySQL;
4. Ištrinkite ibdata1 ir ib_logfile* failus (jie bus sukurti iš naujo, kai iš naujo paleisite MySQL);
5. Įjunkite MySQL ir atkurkite duomenų bazę iš atsarginės duomenų kopijos.

Atlikus šiuos veiksmus ir iš naujo paleidus MySQL, ibdata1 ir ib_logfile* failai bus sukurti iš naujo.

Nuo šiol sukūrus naują duomenų bazę, duomenų bazės lentelės bus atskiruose ibd* failuose, o ne ibdata1 faile – ibdata1 vis tiek augs, tačiau šiame faile bus tik lentelių metaduomenys, o ne patys duomenys. Jei duomenų bazės nebebus, ibd failai bus ištrinti.

Kas tie Log Įrašai ir Kas Juose Yra?

Log įrašų failuose (ib_logfile0 ir ib_logfile1) yra iš naujo atliktų įrašų (redo) įrašai. Jei MySQL staiga išjungiama ir iš naujo paleidžiama, iš naujo paleidus MySQL bus nuskaitomi ib_logfile0 ir ib_logfile1 failai ir bus patikrinama, ar nėra duomenų pakeitimų, kurių nebuvo faile ibdata1. Jei pakeitimų yra, jie bus atkartoti. Kai visi pakeitimai bus atkartoti ir išsaugoti, MySQL bus pasirengusi naujiems darbams.

Kitaip tariant, MySQL naudoja log failus tam, kad užtikrintų duomenų ilgaamžiškumą – variklis sugeba užtikrinti, kad staiga išjungus MySQL ar dingus energijai duomenys nebūtų prarasti.

Gero InnoDB log failų dydžio pasirinkimas yra gero MySQL įrašymo našumo pagrindas – innodb_log_buffer_size parametras turėtų sudaryti 25% innodb_log_file_size vertės.

Poveikis Atkūrimo Laikui

Kaip minėta ankščiau, jei MySQL grubiai išjungiama, iš naujo paleidus MySQL bus nuskaityti abu ib_logfile0 ir ib_logfile1 failai. Tai ir yra pagrindinė priežastis, kodėl yra labai svarbu tinkamai nustatyti reikšmę innodb_log_file_size kintamajam – log failo dydis turėtų būti kuo didesnis, bet ne didesnis, nei būtina. Padidinę log failo dydį gausite geresnį našumą, tačiau tai turi ir trūkumų: tokiu atveju padidės atkūrimo laikas po grubaus išjungimo ar gedimo.

Norint pasiekti pusiausvyrą tarp ganėtinai gero sistemos veikimo ir greito gedimų atkūrimo laiko būtina tinkamai nustatyti innodb_log_file_size reikšmę.

Norėdami nustatyti ir innodb_buffer_pool_size ir innodb_log_file_size reikšmes taip, kad gautumėte gerą balansą, galite vadovautis šiuo metodu:

1. Išsiaiškinkite, kiek RAM turi Jūsų sistema (tai galite išsiaiškinti panaudoję Linux suteikiamas komandas, pavyzdžiui free komandą);
2. Skirkite 75% (arba mažiau, priklausomai nuo serverio apkrovos) visos RAM atminties parametrui innodb_buffer_pool_size;
3. Skirkite 25% vertės, paskirtos innodb_buffer_pool_size parametrams ..._log_file_size.

Santrauka

ibdata1 ir ib_logfile* failai yra itin svarbūs tinkamam InnoDB funkcionavimui – nors kai kuriais atvejais šie failai gali sukelti problemų, dažniausiai šias problemas galima greitai ir patikimai išspręsti.