Dotaz: MySQL a velká disková aktivita po startu

[Petr]

Mám tu databázový server, který mimo jiné zálohuji vždy v noci na druhý stroj. Tím druhým strojem je BananaPi s externím USB diskem. Jedná se o 250GB disk s pomalou přístupovou dobou (50 iops).

Vše funguje parádně, ale pokud se BananaPi restartuje, systém sice rychle naběhne a funguje, ale MySQL ještě tak 2 hodiny pořád průběžně hrabe na disk. Stejně tak při restartu služby MySQL. S databází se sice dá normálně pracovat, ale chtěl bych tomu disku ulevit.

V /etc/mysql/debian-start jsem zakomentoval (dle návodu na webu) položku check_for_crashed_tables, ale to nepomohlo.

Na tom BananaPi jsou denní zálohy. Zatím je nemažu, takže je tak už přes 6300 databází s celkem asi 487000 tabulkami typu MyISAM. Dat je dohromady přes 65GB.

Napadá vás, co ten MySQL server po staru dělá a jak mu v tom zabránit, pokud to jde? Jestli třeba jen kontroluje integritu všech tabulek, nebo sbírá nějaký statistiky, tak kde to vypnout?

S tou databází se zatím jinak nepracuje. Tabulky slouží jen jako záloha. Takže je nic nečte ani se do nich nezapisuje.

Odpovědi

[AlfaSamček]

Strasne vela dat a databaz na taky maly holiaci strojcek...

[dustin]

Taky mi to přijde na takový stroj nepřiměřený požadavek.

Proč nejde ty zálohy držet v dumpu na filesystému, třeba po jednotlivých tabulkách (mysqldump -tab) a třeba i bzipované? Jestli dobře počítám, má každá db cca 10MB, to by bylo z dumpu nalité přes LOAD INFILE během chvilky.

Navíc by to usnadnilo i zálohování - soubory snadno překopíruješ na zálohovací disk/server.

[Petr]

Na to jsem se sice naptal, ale dumpy těch databází jsou na NASu. Jednou za týden to jde ještě na pásku. Funguje to tak, že hlavní server (master) se replikuje na druhý server (slave). V noci se na replice udělají dumpy a ty se uloží na NAS.

Z toho NASu si je natáhne BananaPi a převede je opět na funkční databáze s tím, že je to vlastně funkční záloha zálohy s denními obrazy. Takže pokud by bylo potřeba zjistit, jaká konkrétní data byla v určité databázi před týdnem, před měsíce a podobně, lze buď obnovovat ty zálohy z dumpů na NASu, nebo se rychle mrknout do funkčních aplikací na BananaPi.

Aktuální ostrá data jsou tedy na hlavním serveru a na replice. Denní zálohy ve formě dumpů na NASu, týdenní na pásce.

Ten banán je jen na pohodlné občasné nahlédnutí do minulosti, což se dělá minimálně - možná tak 1x za měsíc, někdy ani to. Běží to tu druhým rokem bez problému. Jen když se to restartuje, tak ten disk se něco naběhá.

[Profes0r]

tak tam daj SSD a hotovo...

[Petr]

Přesně taková je dnes doba.

Je to pomalý? Dej tam víc RAM. Dej tam lepší procesor. Dej tam SSD. Furt to nestíhá? Přidej další servery. Pořád nic? Tak to přesuň do cloudu a plať si třeba 5 mašin. Co 5 mašin, plať jich 20, nebo 50, nebo ...

A co optimalizace? Nepomohla by jen úprava konfigurace či algoritmu?

Ale prosímtě. Kdo by se s tím páral, když máme ty internety, kloudy a jiný čmoudy.

Tak já jsem asi už hodně starej, zabedněnej a nemoderní, když mě výše uvedenej postup připadá postavenej na hlavu.

Ale nakonec jsem to vyřešil. Ono to po zaremování té položky "check_for_crashed_tables" chtělo jen restartovat celý OS. Já to testoval jen tím, že jsem udělal "service mysql restart", což nestačilo. Chtělo to prostě reboot celý mašiny a teď už je klid.

Každopádně díky za komentáře. Už delší dobu se podezírám, že jsem starej dinosaurus. Holt vyrůstal jsem ješte na osmibitech.

[dustin]

Reboot mi nepřijde jako vyřešení problému s přístupem přes pomalé USB na disk s obrovským množstvím malých souborů...

Ten check na poškozené tabulky není až tak zbytečný, obzvláště u MyISAMu stačí tvrdý shutdown a crashed tabulka je na světě.

Ale držím palce, třeba ti to bude i nadále fungovat...

[Petr]

Mě se líbí, jak všichni řeší vše okolo a ne podstatu dotazu.

V rychlosti přece není vůbec, ale vůbec žádný problém. Na ty potřeby, co se s tím dělá, je to rychlí jako blesk. Je to vyloženě pasivní skladiště dat. To jsem přeci psal hned v úvodu. Je to záloha zálohy. Leží to pasivně na disku, nikdo s tím nepracuje. Co by se na tom mělo jako poškodit? A i kdyby, každá tabulka je tam v desítkách, někdy i stovkách kopii. A když chcípne disk, nalije se to na nový z dumpů uložených na NASu. Když chcípne i NAS, vezme se to z pásek. Pořád je to jen obnova zálohy. Živý server je úplně jiný stroj.

Při tvrdým restartu může dojít k poškození MyISAM tabulky asi těžko, když se s ní nepracovalo. Nebyla prostě otevřená, proč by měla být. Je to pasivní záloha. Nikdo jí nečetl ani do ní nezapisoval. A i kdyby, poškodí se spíš index než data. Takže myisamchk s příslušnýma parametrama založí index znovu.

V my.ini je dokonce parametr myisam-recover, který se dá nastavit tak, aby když se na tabulku šáhne (až s ní chce někdo opravdu pracovat) a zajistí se, že je poškozena, provede se automaticky oprava. Takže ve skutečnosti není v mém konkrétním případě vůbec potřeba vše prověřovat dopředu při startu mysqld.

Proto odstranění parametru check_for_crashed_tables ničemu neublíží a reboot byl řešením toho, aby ta změna začala platit. Jediné co nevím je, proč se to neprojevilo hned při "service mysql restart", ale až po rebootu. Přitom restart služby spouští stejný script, jaký se startuje při bootu. Ale po tom už pátrat nebudu.