[ bjevta @ 07.12.2010. 21:23 ] @
Situacija je ovakva:
- baza (InnoDB) ima 100+ tabela, od kojih 4 sluze za e-mail notifikacije,
- u te 4 tabele jedan thread intenzivno upisuje ko, kad, šta treba da primi u e-mailu,
- drugi thread po zadatku kreće na svakih 5 minuta i briše (kaskadno brisanje uključeno) record-e koji imaju flag "mail sent"
- log MySQL-a raste 50 MB/min (!?). Ovo mi je rečeno, pošto se dešava na production serveru sa puno korisnika.
- logovanje MySQL-a transakcija po ovim mail tabelama uopšte nije bitno. Ako se i nešto desi, ovi mail-ovi nisu previše bitni.

Cilj:
- svesti logovanje na razumnu meru. Ako može, isključiti log nad ovim (mail notification) tabelama. Da ima loga al, ne za ove tabele.
- ograničiti veličinu loga

Rešenje?

Najbolje što mi je palo na pamet jeste da ove 4 tabele prebacim na MyISAM. Sutra treba da probam. Valjda MySQL neće onda da loguje svaki upis, update i brisanje po njima?

Da li postoji neka formula za optimalan log? Ja sam predložio da se ograniči na 1GB approx mada, mislim da je i to mnogo.

Ima li neko mudrijašku ideju šta da radim?
[ bogdan.kecman @ 07.12.2010. 21:45 ] @
kao "log" pretpostavljam da mislis na "binary log", na zalost binlog-ignore-table ne postoji.... prebacivanje u myisam nece pomoci posto to i dalje ide u binlog, jedino da prebacis u posebnu bazu i onda nju da dodas u binlog-ignore-db. Ako to radis, obrati paznju da moras da radis

mysql_use('ignorisana');
mysql_query('update tabela .... )

ako probas

mysql_use('normalnabaza')
mysql_query('update ignorisana.tabela .... )

to nece da radi, tj radice upit ali ce da ode u binlog, dakle binlog-ignore-db gleda koja je "default" baza a ne koja je u upitu

dalje, za innodb tabelu to sto radis je "pakao" posebno ako ne koristis innodb-file-per-table posto onda uzasno fragmentises ceo innodb table space... mnooooooooogo iskusnija fora ti je, posebno posto ti to nisu vazni podaci i nista strasno se nece desiti ako ostanes bez njih da to stavis lepo u MEMORY tabelu i jedan tred pise, drugi tred brise, tabela je relativno mala, nema fragmentacije, sve super brzo ... nije persistentna, dakle ako resetujes mysql ostaces bez tih podataka al sam kazes da nisu znacajni ...
[ bjevta @ 07.12.2010. 22:36 ] @
hvala, ova fora sa MEMORY table mi uopšte nije pala na pamet a zvuči mi kao "real thing".

mogu li da ukljucim file-per-table samo za odredjenu bazu ili to radim na nivou MySQL instance?

da li nešto dobijam/gubim što se tiče pouzdanosti ako predjem na file-per-table? jasno mi je da je manipulacija lakša, ja sam prebacio moj MySQL na file-per-table. Ovo pitam za production server na Linux-u i sasvim pristojnom hardveru.

[ bogdan.kecman @ 07.12.2010. 22:44 ] @
prebacivanje na file-per-table je poprilicno mucenje posto zahteva dump/restore posto ako startujes mysql sa postojecim tablespace-om pa kresnes file-per-table samo nove tabele ce biti u zasebnim fajlovima ..

sto se tice sta se dobija a sta gubi sa file-per-table ... malo je kompleksnija prica, generalno imaju i jedan i drugi dosta prednosti i mana tako da .. dugacka je prica a ja sam umoran ... mozda neki drugi put ..

sto se tice MEMORY - yup, to ti je resenje 1/1 samo ako imas dovoljno rama da moze da ti stane ta tabela u ram (ako taj thread koji cisti podatke to radi dovoljno brzo :D )