MySQL slow queries

Zdravo,

MySQL DB server sa bazom koju cine samo innodb tabele ima problema sa slow upitima. Slow query log je pun SELECT/UPDATE upita koji traju po 10, 20, 30, 40, 100s...
E sada kada se taj isti SELECT upit (za koji je u logu zabelezeno da je trajao recimo 80s) pusti kroz EXPLAIN, pokazuje da pretrazuje samo 2 reda od nekih npr 700 000 ili vise. Indexi su postavljeni na pravom mestu i mysql ih koristi kako treba. Takodje, kada se upit pusti kroz neki klijent, rezultat se dobija momentalno tipa 0.015s ili slicno.

Kada se slow query log pusti preko mysqldumpslow sa top 10 slow querija i isti analiziraju kroz EXPLAIN i strukturu tabela rezultati su sledeci:

- grupe slow querija TOP 2,3,5,6,7,8,9,10 su kratki SELECT/UPDATE koji na ispravan nacin koriste indexe. Za UPDATE upite sam koristio proveru EXPLAIN SELECT....
i mislim da je to ispravna analogija za proveru UPDATE kroz EXPLAIN. Nijedan query ne ide kroz full table scann i max broj redova koji se pretrazuje je 2 i to samo kada
ima 2 zapisa kao rezultat.

- top 4 slow query je duzi JOIN query koji nisam uspeo da pustim kroz EXPLAIN. Provericu ovih dana da li su to temp tabele ili da pustam segment po segment upita.
Pretpostavljam da povecanje join cache moze mozda biti deo resenja. Inace odnos tmp tabela hdd/ram je sasvim ok.

- TOP 1 slow query je COMMIT. Negde sam procitao ranije da ovi simptomi (upiti koji su kroz EXPLAIN ok a javljaju se u slow qery log kod innodb sistema), ukazuju na
transakcije koje blokiraju jedna drugu i prave beskonacnu lock petlju - deadlock, sve dok mysql ne postane svestane toga i skine jednu od njih. Prakticno svi upiti u okviru transakcije koriste indexe i dobro su optimizovani kada se puste kao single query, medjutim zbog deadlock-a traju dugo.

Ukljucio sam na kratko innodb monitor da upisuje u error log ali nisam video nista sto ukazuje na deadlock. Inace error log se za razliku od general i slow loga nije punio uopste do danas i bio je prazan u zadnja dva meseca od kada je server neprekidno up (sto i nije nesto bitno za ovu pricu - u my.cnf je bila putanja do praznog error loga, a ps aux | grep mysqld je pokazivao putanju error loga sa kojom je mysqld startovan i koja ne postoji na hdd). Restart mysql-a je resio to.

Inace verzija mysql je 5.0.84 a slow guery je bio upaljen od ranije sa default vrednostima. Stavio sam sada da loguje sve upite koji su duzi od 3s i sve upite koje ne koriste indexe, pa da vidim ovih dana da li ce pokazati nesto novo.

Eksperimentisao sam i sa maatkit skriptama za parsovanje logova mk digit i mk advisor, ali mi se mysqldumpslow cini sasvim ok, jednostavan i pregledan.

Pozdrav.

Sada se setih da sam video danas da postoji cron job koji je neko postavio ranije i koji radi sve vrste table maintenance za sve tabele u bazi, svakog dana: check, analyze, repair, optimize. Baza je nekih 3GB i full innodb. Skinucu taj cron jer je mozda i to deo problema. Repair po zvanicnoj doc radi samo za MyISAM, a bas na ovom forumu sam i dobio koristan info da od analyze i optimize nema mnogo koristi ni za myisam ako nesto krene lose, a kamoli za innodb.

analyze jeste koristan ali nema svrhe mnogo na innodb-u da se tera "Svakodnevno", posebno ne na 5.0 ..
optimize/repair na innodb-u rekreiraju tabelu od pocetka .. bilo kakav update ce tu da sedi i ceka da se tabela rekreira .. to ima korist u tome sto ce se tabela defragmentisati ali raditi to svakodnevno na 3G innodb-a nema smisla


ti upiti traju toliko ili
- zato sto se medjusobno zalokuju
- zato sto im je tabela zalokovana sa optimize
- ili se nesto drugo zakuca .. na 5.0 ima dosta stvari koje mogu da se zakucaju (query cache prvi) .. tako da ako ti izbacivanje tog skripta koji radi repair ne pomogne ugasi query cache pa probaj opet

Potpis

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

ako se dobro secam, MySQL je, do verzije 5.5, imao default vrednost innodb_buffer_pool_size=8M.
Od verzije 5.5 to je 128M. ovaj parametar JAKO utice na performanse.

Predlazem da proveris my.cnf. Potrazi innodb_buffer_pool_size varijablu i setuj innodb_buffer_pool_size=512M, na primer.
sto vise, to bolje, up to 70% RAM-a.
Ako vrtis jos nesto na tom serveru, probaj sa 1G, za pocetak ili slicno.

u medjuvremenu, otvori mysql command promtp i otkucaj: show variables like 'innodb_%';
rezultat postuj ovde, da pogledamo.

Potpis

Acta, non verba!

Pozdrav svima.

Iskljucio sam skriptu koja radi repair/optimize pa cu pogledati sutra da li je pomoglo nesto.

Innodb je konfigurisan ovako:

innodb_buffer_pool_size 1GB #Mislim da je vrednost OK, ali ima prostora za povecanje jos, pa planiram da podignem do 3GB

innodb_flush_log_at_trx_commit 1 #Planiram da stavim 0, jer je Bogdan ranije lepo objasbio da flush na hdd posle svake transakcije nema mnogo smisla na virtualnim masinama, jer to VM OS i ne radi bilo sta da se stavi

innodb_log_buffer_size 8MB #Mislim da je OK vrednost

innodb_log_file_size 5MB #Za ovu vrednost mislim da je jedan od uzroka losih performanci. Eksperimentisao sam ranije na test serverima sa promenom velicine innodb log fajla i nekad je uspevalo a nekad ne iako sam isao po standardnoj proceduri (shutdown mysql,..). Cak sam nasao cini mi se i proceduru na percona mysql blogu kako odrediti pravu vrednost, medjutim meni dok sam eksperimentisao nije pokazalo nista. Verovatno zato sto na test serverima nije bilo nikave aktivnosti osim moje :). Planiram da stavim 512MB ili 1G.


innodb_thread_concurrency 8 #nisam siguran kako bi promena ovog parametra uticala i da li bi uopste uticala



Sto se ostalih parametare tice:

query cache size je 128MB, ugasicu ga pa cu da uporedim po Bogdanovom savetu. Mada cu prvo da proucim sta to tacno radi, jer sam imao drugu sliku o ovom parametru pa sam malo zbunjen :).

join buffer je 2MB i cini mi se da je to malo, pa planiram da povecam. Ali kao i za ovo gore kada malo proucim.


temp size je dosta veliki 1GB i to necu da diram.


Napravio sam novi slow log i ubacio da loguje sve koje se izvrsavaju duze od 3s i sve koji ne koriste indexe. Tako da je sada slika drugacija i mysqldumpslow je drugacio grupisao upite, najvise zbog toga sto je stari log bio star 7-8 meseci i sto su ranije postojale jos neke baze. Sada se commit ne javlja u top 10, jedan query sam identifikovao i testirao sa dodavanjem indexa. Medjutim ostali su ok kada se puste samostalno ili kroz explain. Tako da i dalje sumnjam na deadlock.

U vezi sa tim hteo sam opet da pustim innodb monitor u error log na nekih sat vremena, medjutim error log je opet bio izbrisan i imao velicnu 0! Problem i neslaganje je do my.cnf. Pod sekcijom [mysqld] je putanja error loga koji se punio neko vreme a zatim je bio obrisan tj. velicine 0. U sekciji [mysql_safe] je putanja do fajla koji ne postoji. U skripti mysql koja je u /etc/init.d takodje je putanja do nepostojeceg error loga iz [mysql_safe] (verovatno cita iz my.cnf).

Nema veze sa temom ali me interesuje kako da izbegnem ovo neslaganje i sta je svrha dve lokacije za error log. Da li da stavim istu putanju na oba mesta? Pretpostavljam da mozda iz nekog razloga (innodb?) mysql napravi neki safe shutdown/start i onda preuzme putanju error loga iz [mysql_safe] sekcije u my.cnf.

Nisam obratio paznju na uptime pa da vidim da li je bilo nekog internog restarta.

s moje tačke gledišta my.cnf je dovoljno dobro podešen da ne bude uzrok opisanih usporenja. sigurno ima nešto da može bolje al, da vidimo šta se može s ovim što imaš:
- cron i slično, to definitivno drži isključeno dok tražiš uzrok
- pregledaj upite sa join-ovima. često je problem joinovanje s deteta na parent pa na drugo dete (N-1-M) ili spoljno spajanje (LEFT JOIN). to ne prija ni jednoj bazi. ovo zna toliko da ubije performanse da ne mogu da ti opištem, pravi show stopper.
- indexe gledaj da postaviš tako da imaju što više distinct vrednosti. ako treba, ubaci kompozitni index ili prepravi postojeći (DROP/CREATE). ne pomaže uvek al, vredi probati.
- merenje radi tako što kucaš EXPLAIN SELECT SQL_NO_CACHE <upit>, u protivnom se čita iz keša i ne možeš da dobiješ prave rezultate.
- pređi na 5.5, ako ikako možeš. mysql se brzo razvija i bitno je na kojoj si verziji. o tome smo ovde razglabali naširko, bogdan samo što roman nije napisao.
- vidi parametre OS-a, imaš u skorašnjim postovima korisne tip-ove.
- pošto je VM u pitanju, samo mogu da kažem da odvojiš što više RAM-a: zvekni te innodb bafere na 3GB kao što si nameračio i raspali po testovima.
- veoma bitno, proveri da li se ti upiti (join) swap-uju na disk. ako da, to moraš da izlečiš.

i, obavezno javi šta si napravio.

Potpis

Acta, non verba!

Definitivno je optimize skripta bila jedan od uzroka losih performansi. Sada mysql radi mnogo bolje.

Nasao sam jos jedan od mogucih uzroka. Skripta koja radi svakodnevni backup lockuje celu bazu tokom bekapa tj. mysqldump ne ide kroz transakciju. Planiram da promenim to i da stavim --single-transaction opciju u dump. Doduse ima jedna tabela koja je MyISAM, pa cu mozda pored bekapa kompletne baze plus samo za tu myisam tabelu da radim poseban bekap sa lock tj. --opt opcijom. Za svaki slucaj, iako je tabela zanemarljivo mala :).

Sledece sto planiram da uradim je da povecam innodb_log_file_size sa 5MB na definitivno 128M. To se uklapa u generalnu preporuku (128+128) 25% od innodb_buffer_pool_size u ovom trenutku. Kasnije u sledecoj fazi planiram da povecam oba parametra tako da innodb buffer bude priblizan velicini tablespace. Radio sam i kalkulaciju velicine innodb log fajlova po:



Dva puta pri ovoj kalkulaciji sam uhvatio pikove od oko 4MB/min sto se i uklapa u kalkulaciju od 128M (4*60/2 loga - 128M). Doduse ostalih 7-8 kalkulacija za innodb log su bile ekstremno male, ali pretpostavljam da tada nije bilo akktivnosti na serveru.

Inace, sam innodb tablespace je izlgeda prepun "smeca". Velicina je 2.5 puta veca od velicine innodb tabela i indexa. Tako da i to planiram da re-kreiram. Verovatno su ranije postojale jos neke innodb tabele/baze na serveru. Necu da grunem sve promene odjednom da bih imao kontrolu sta povecava performanse a sta ne ili cak pravi jos veci problem.

Resio sam problem sa error logom tako sto sam i u mysqld_safe sekciju stavio istu putanju do error loga kao i u mysqld sekciji my.cnf fajla. Ukljucivao sam innodb monitore standardni i jos dva dodatna. Medjutim nisam nasao nista interesantno. Pretrazivao sam po deadlock, FK error i po bilo kom drugom error-u. Ostale sekcije output-a kod innodb monitora mi iskreno nisu bile bas mnogo razumljive tj. nemam predstavu kako mogu da ih iskoristim (npr. wait queue prazan, nema deadlock, nema error,..). Nije bilo niceg sto bi ukazivalo na neki innodb problem ili smernicu za eventualni problem.

Planiram da za innodb flush method stavim O_DIRECT, samo ne znam da li to uopste ima smisla za virtuelnu masinu kao sto je slucaj i sa flush na hdd posle commit-a.



Bjevto, da li pod ovim mislis na to da li se interne temp tabele koje mysql pravi pri join upitima (ili pri nekim drugim akcijama) upisuju na hdd ili u memoriju? Ako mislis na to, to je u redu. Odnos temp tabela HDD/RAM je manji od 1%.

Inace, optimatizaciju slow upita sam ostavio za kraj. Delom zbog toga, sto 2/3 upita koji se javljaju u slow logu/mysqldumpslow su dobro optimizovani i koriste indexe kako treba kroz explain (hvala za EXPLAIN SELECT SQL_NO_CACHE savet Bjevto!). Delom da prodje vreme jer sam novi slow log kreirao skoro, a najvise zbog toga sto sam tu najtanji.
Jedan spori upit sam i sredio dodavanjem indexa i testirao na testnom serveru, pa cu prvo njega da primenim u produkciji.

Pozdrav.

optimizacija mysql servera:
innodb_log_file_size – 256M do 1GB. Veca vrednost povecava performanse ali drasticno usporava “recovery time” tj. vreme koje je mysql-u potrebno da izvrsi “oporavak” innoDB table space-a posle “nasilnog” prekida rada. Ako koristite velike blobove, jako je bitno da ovaj parametar ima “vecu” vednost



Query cache pravi hash upita (Celog upita) i onda kesira rezultat. Kada ti napravis upit on opet napravi hash, proveri da li ima takav i ako ima vrati ti rezultat iz kesha, ako nema izvrsi upit, kesira ga i vrati ti rezultat. U meta od upita se nalazi od cega "zavisi" (baza, tabela ..)

Svaki put kada uradis update/delete/insert .. (neki data modifying statement) on mora da radi invalidatizaciju kesa i da brise sve upite koji imaju veze sa tim sto si ti promenio. Ta procedura je prilicno kompleksna.

- ako imas mnogo promena nad tabelama query cache moze da uspori stvari (posto ne stize da zadrzi upite dovoljno dugo da bi imao smisla i nekog ubrzanja a usporava update zbog invalidatizacije)
- bilo je par nezgodnoh bagova za qcache-om

Ja sam ti rekao da ubijes qcache skroz da bi bio siguran da nije do njega uglavnom zbog bagova... to je relativno nov deo mysql-a i nije bas naj-idealniji (dosta je bolji u 5.5 ali i dalje .. mozda je ostao jos neki bug)


ili ostavi samo u [mysqld_safe] ili stavi isto



Nece ti to nista pomoci. Vidi da li mozes da iskoristis mylvmbackup (da li je sysadmin bio dovljno pametaj da turi datadir na lvm?), ako ne mozes, ubedi firmu da pljune pare MEB (mysql enterprise backup) - mozes da skines trial sa https://edelivery.oracle.com/ .. to ti je najbrzi i najsigurniji nacin da napravis bekap



Dump -> Restore resava sve probleme :D. Ako to vec radis a datadir ti nije vec na LVM-u eto ga idealan trenutak da to promenis :) i onda ti mylvmbackup resava bekap problem



Bilo bi zanimljivo ako mozes da napravis neki test sa ovim ... obrati paznju isto da neki kerneli imaju problem sa ovim tako da .. mislim licno, ali ne znam sigurno, da neces dobiti nista sa o_direct

Za optimizaciju par hintova
1. prvo kada se ulogujes na mysql, radi to direktno iz konzole, preskoci raznorazne gui-e i ekipu
2. pre bilo cega kresni jedan SET SESSION query_cache_type = OFF; da budes siguran da te ne za... qcache
3. onda na tenane radi explain, select etc etc .. za svaki select radi SELECT SQL_NO_CACHE .. 3 puta za redom i gledan najgoru vrednost
4. 5.5, 5.5, 5.5, 5.5, 5.5 ... set profiling = 1 ... http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html ... imas profiling i u 5.0 ali 5.5 je toliko bolji :D

Potpis

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

Nije konfigurisan lvm, ako sam znao da trazim sta treba (lvm lvdisplay, lvdisplay, lvmdiskscan, lvscan, pretraga po conf fajlovima,...). Sto se tice MEB/MySQL Enterprise :D :D, nista od toga. Bilo je ozbiljnih predloga (koji su aktuelni i danas i potezu s vremena na vreme) da se plati enterprise verzija + support, srede serveri/upiti/okruzenje, napravi ozbiljan mysql tim i nauci mnogo od supporta samo "gvirkanjem" kako support sredjuje stvari, podesava konfiguraciju i upite.




Bas to sam i uradio, stavio sam istu putanju u obe sekcije i to je proradilo. Medjutim vec sledeceg dana error log je bio prazan ponovo. Posle malo mozganja i testiranja shvatio sam da se mysql ponasa kako ne bi trebalo da se ponasa :). Naime, pored error loga bio je jos jedan sa ekst. log-old, nisam na to obracao paznju ranije jer sam mislio da je to nesto staro. Medjutim stat za oba fajla pokazivao je isti datetime, koji se poklapao sa vremenom backupa. Mysqldump u skripti je regularno sa flush logs opcijom i kako se dva puta okida - za mysql i radnu bazu, error log se rotira 2 puta i originalni error log nestaje! Proverio sam to sa FLUSH LOGS. E sada koliko znam, to je normalno ponasanje (da se pravi novi log a postojeci rotira sa err-old) samo kod default pocetne konfiguracije kada je error log u formatu hostname.err. Da li je to neki bug ili zbog toga sto postoji putanja i u mysqld_safe sekciji, uglavnom dodao sam liniju da arhivira aktuelni error log pre svakog dumpa. Proverio sam i na drugim serverima, cak i neke sa istom verzijom i nigde se ne rotira log posle flusha. Doduse na drugim serverima je samo jedan path do error log i to samo u mysld sekciji.


Sto se tice servera, stvar je na cekanju zbog nekih totalno drugih stvari a samim tim i optimatizacija i konfigurisanje. Uglavnom sve vise mi se dopada ideja za sprecavanje swapa (swappiness na 0), koja je pomenuta i ovde. Doduse ima i drugih (neutralnih) misljenja u vezi toga na netu. Danas sam uradio i nekih 25-30 rucnih "racunaljki" iz show global status tipa br.inserta/commit, read/write, full join/sec... Necu biti tu nekih par dana, pa kada se vratim ponovicu "racunaljke" i sledeceg puta i zapisati :) i pustiti ovde. Uglavnom ono sto mi je ostalo upecatljivo (i sto sam zapamtio) je da je npr. innodb page free je 0, sto bi trebalo da ukazuje na nedovoljan innodb pool size; % temp tabela na disku je manji od 3% i to bi trebalo da je ok; server je vise read nego write tipa read - 300/s, write 2/s; upiti iz cache u odnosu na ukupan broj upita (cache + no_cache) su oko 40%, innodb hits ratio oko 98% sto je ok,...

Pozdrav.

Ako ces da cisti innodb table space (dump/restore) taman imas priliku da stavis lvm pa datadir na njega


MEB radi i sa GPL mysql-om, skines ga sa edelivery i pokazes gazdi kako do jaja radi :D pa ako se gazdi ne svidi a ti ga skines sa masine (ili ga ostavis nadajuci se da te oracle advokati nece napipati :D :D :D)



nema sta da se gvirka :D .. support i consalting kod nas bas imaju cilj da te nauce - da bi nas manje smarao :D .. tako da se mi vrlo potrudimo da ti pokazemo kako ti da resis problem kako sledeci put ako ga imas mozes da ga resis sam a ne da smaras nas koji imamo dovoljno problema i bez tebe :D ... tako da, nema sta da gvirkas, 30% nasih support inzenjera su nekad bili nasi klijenti pa smo ih obucili pa su presli kod nas :D

nisam te skontao sta ti je sa logom ..

swappiness je desktop stvar, za ozbiljan server razlog da se proces baci na disk a kesira pristup disku je vrlo diskutabilna opcija a kada je DB u pitanju, posebno ako je to innodb swappiness moze samo da smeta, dakle gov*o na nulu ...

najveci problem je tu sto debilni kernel i kada mu kazes da oces swapinnes 0 oce da filozofira

Potpis

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

Ta ideja mi se bas svidja :) :)

Sto se tice samog mysql, nisam jos optimizovao na produkciji. Ceka se fizicka masina ili sta vec.

Uradio sam inicajlnu optimatizaciju na testom serveru koji je imao ista podesavanja i variable kao produkcija, samo sto je daleko slabija virt masina.

query cache je sa nekih 256M smanjen na 10M i samo sa tim se dobilo ubrzanje od nekih 25%. Sa ugasenim query cache test koji imitira load na produkciji je bio sporiji skoro 5x. Sa query cache od 64 i 32M bilo je neke neznatne promene, i tek sa 20M se dobilo primetno ubrzanje a sa 10M najbolji rezultat. Iako sa 10M skoro da nema slobodnog prostora u cache (free space) i brojka izbacenih upita iz kesa zbog nedostatka prostora se kretala oko 60000 tokom trjanja testa (zaboravio sam koliki je ukupan broj querija i uvezi sa tim ratio)

Innodb size je povecan do krajnjih granica nekih 80% RAM (bilo je pre toga 50% na testnoj masini) a innodb log na 128M (pre toga default 8M). Innodb promene nisu pokazale neke vidljive rezultate, ali ocekujem da ce slican odnos innodb konfiguracije na produkciji ubrzati MySQL najvise (zbog mnogo veceg RAM-a).

Optimizovao sam na drugom mestu 5 querija koji se konstanto javljaju u mysqldumpslow, ali nisam ubacio te promene jos. Ostala su mi jos 2 join upita da sredim i u vezi sa
tim da razmotrim join buffer size.

Temp tabele koje se prave na disku sam spustio ispod 13% i mislim da je to dobar odnos.

Imam jedino dilemu kada krenema na produkciji da li da pravim dva ibdata fajla, nesto kao ibdata1:50M;ibdata2:50M:autoextend ili da ostavim jedan kao i do sada. Neznam
kako to utice na performance. Sto se tice uloge dva 2 ili vise ibdata fajla da se prevazidje limit OS fajl sistema ili brzina inicajlnog restore cele baze, to mi nije
toliko bitno.

Pozdrav.

cak i za srpske uslove se isplaty mysql support. za 5000$ u najskupljoj varijanti, to je 300EVRA MESECNO!!!!, za te pare ne mozes da zaposlis losed DBA ni u Jugi a kamoli na zapadu .. da ne spominjem da ako hoces tog dba da zaposlis za 300e mora das drzavi jos toliko za poreze i sra*a dok ovde platis 300e i to ti je cist trosak koji odbijas od poreza ..

O kvalitetu koji dobijes za tih 300e mesecno ne mogu ni da pricam, ako zaposlis dba, kakav god da je, on je samo jedan, sigurno ne zna sve i nekad mora da spava, ovako dobijes gomilu strucnjaka koji rade zajedno na tvom problemu ... da ne spominjem sto za tih 300eur dobijes i gomilu drugih stvari (MEM, MEB ...)


ako ti sa 10M radi bolje nego sa 256M znaci da imas mnogo updateova koji zabadaju kesh tako da... valjda je sve jasno




potpuno je isti djavo dal ce bude jedan ili 30 fajlova, mysql ne radi "striping" kada ima vise fajlova vec se nastavljaju jedan na drugi

Potpis

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

Implementirao sam neke stvari na produkciji i odmah je bila primentna razlika. Ono sto je u startu napravilo "razliku" su innodb podesavanja Innodb size i innodb log. To je znatno ubrzalo server i db procese. Takodje, skinuo sam mysql DNS resolve i definisao pritup bazi samo na osnovu IP i smanjio query cache.

Ima jos mnogo prostora za poboljsanje, sama baza je pre-dimenzionisana tipa svuda je bigint umesto int bez potrebe, svaka tabela koja ima primary kljuc obavezno
ima nepotrebno jos jedan unique za isto polje a cesto i jos jedan dodatni obican index za isto polje, fale indeksi na pravim poljima itd...

Explain, profiling i procedure analyse - fenomalne stvari za optimizaciju upita (sve dok ne naletim na neki kilometarski sa 5 join-a :D). Inace jedan od veoma dobrih izvora za optimizaciju: hackmysql.com

Sto se tice mysql supporta meni licno se najvise svidja ovaj deo :D




Isprobao sam par solucija mysql backup-a, ali cu otvoriti novu temu vezano za to radi lakseg pretrazivanja.

Pozdrav.