Mysql innodb 5.5.22 ibdata porasla na 27GB

Veoma cudan problem, kod novog korisnika podesili smo bazu i poceli su da rade. Nakon par dana prijavljuju usporenje rada i kada smo poceli da pregledamo sta se desilo primetili smo da je ibdata porasla na 27 GB. Red velicina je da bi mysqldump baze trebao biti nekih 15tak MB. u tabelama nema fantomskih redova ali bilo koji upit uneredi performanse potpuno. nikad nam se ovo nije desilo. u alatu SQL Yog kada smo isli na desni klik najvece tabele pa na Show Advanced Properties pisalo je da tabela ima 27miliona redova a objektivno bi trebala imati oko 2000.

da li je moguce da nekom greskom neki proces u bazi sibao neke fantomske redove u nju? prosto ne verujem da se ovo desilo ali moram da pitam.

tek cemo pokupiti log fajlove pa ih analizirati da li imaju greske i kakve.

Ako ti nije odvojeno svaka tabela u svoj fajl, a ocigledno nije, ibdata ti drzi ceo tablespace. Prvi lek bi meni bio dump i restore, uz, u medjuvremnu, stavljanje innodb file per table - mada naravno sve te podatke mozes da izvuces i iz information_schema.

Pogledaj koje sve tabele imas, i pogledaj koliko imaju redova. Ako ti kaze da ima 27 miliona, verovatno ih ima (tj. sigurno), a zasto - tu ti mysql ne moze pomoci, to si sam spucao iz koda. Osim ako nemas general log (sto niko normalan nema na produkciji), tesko ces u DB logovima naci nesto pametno.

Sto se tice upita koji "unerede performanse", ja bi prvo pogledao indexe - ako na tabeli imas gomilu indexa svaki insert/update/delete mora da ih update-uje. Pogledaj i trigere i sta imas u njima, mozda ti nesto ne dira indexe, vec okida trigger koji se sporo izvrsava?

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

afaik yog radi select count(*) tako da tu nema greske .. e sad ako cita show table status, sto ne bi, posebno ne za innodb, onda moguce da prijavi glupost .. uradi sam select count(*) pa vidi koliko ima slogova

sto se tice ogromnog ibdata fajla, ibdata fajl se nikad ne smanjuje, uvek samo raste, cak i ako se koristi file-per-table, to je by-design. da bi se smanjio mora se uradi dump svih baza, brisanje celog datadir-a, dizanje blanko mysql-a i restore dumpa (da znam, smor) ... 5.7 je nesto bolji po tom pitanju ako se koristi file-per-table od prethodnika ali daleko od toga da je resio problem.

brzina rasta ibdata fajla najvise zavisi od velicine i vremena trajanja transakcija. ako zelis da napravis ogroman fajl, napravi veliku transakciju i ostavi je da bude aktivna par dana pre nego uradis sta god, commit ili rollback .. za to vreme normalno koristi server i gledaj kako ibdata fajl kvasa ..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

kod mene je konkretno slucaj izgleda sto je kolega pisao update kolone bez te kolone u WHERE uslovu. ne znam u kom svemiru i pod kojim uslovima se sta desilo ispod haube da bi tako MYSQL odreagovao. kad sam seo da istestiram slucaj pod kojim puca desilo se to da kada sam stavio u WHERE tu kolonu koju update-ujem onda je odradio brzinom kojom sam i ocekivao. taj WHERE koji sam stavio je obuhvatao sve redove koje sam i mislio azurirati. nasao sam na mysql forumu nekom da se lik zali da mu na verziji 5.5.8 povremeno puca neka funkcija a prethodno je radila 4 godine.

sumnjao sam da transaction isolation level pravi problem, totalno nelogicno, tj da se default-ni promenio u odnosu na prethodne verzije.

@bogdan.kecman baza je baferovala update u nedogled i zapamtila da je baza 27GB. posle restarta baze kao da nije ocistila buffer i ostala je ta velicina iako u sustini de fakto nema tih slogova. a select count(*) ne moze ni da izbaci rezultat. u err fajlu nema vidljivih gresaka.

neobjasnjivo ali mi nije jasno da li je moguce da smo na neki uvrnut nacin naleteli na neki bug MySql-a. skoro je i kolega naisao na neku glupost sa datumima koju je takodje pronasao da je bug.

to je potpuno legitimno, cak stavise najcesce za update nemas tu kolonu u where uslovu vec u where imas PK ili tako nesto a updateujes neku value kolonu




nisi ovo bas najsrecnije objasnio



5.5.8 ima brdo bagova sa stored procedurama i funkcijama, isto i 5.6 prvih nekoliko verzija i 5.7 prvih par verzija
takodje 5.5 ima inkompatibilnosti sa 5.1 isto i 5.6 i 5.7 ... 5.5.8 je star nekoliko godina tako da je prilicno nebitan danas, zar ne


jok


pazi mysql ima "statuse" tabela koji se updateuju nekim mehanizmom i kada uradis optimize table ... uradis optimize i dobijes full statistiku kako valja
tih 27G - to je ibd ili myisam? filepertable? odradi check te tabele moguce da imas korupciju iz ko zna kog razloga



moguce da ste uboli bug, ne bi bio ni prvi ni poslednji, ali nadjite kako ste to uradili u svakom slucaju

pocnite sa tim da uradite check tabele, onda optimize

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Pade mi na pamet, moguce da je bio neki temporary table, mozda neki veliki join? Malo mi je nategnuto, ali moguce da je to odgovorno za bar deo problema..... tmp tabele idu u ibdata, koji, je'l, nikad se ne smanjuje. :(

Zato ja volim file per table. I dalje topla preporuka za dump, promenu setovanja i restore. Ako je jedna tabela, lako ces povratiti prostor kad je file per table, samo uradis alter table engine=innodb (iako vec jeste).

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'