tips&tricks
- odvoj app i db servere, mnooogo ce bolje sve raditi ako ne mesas tomcat i mysql na istom serveru
- tmp u ram samo pod retkim uslovima (ako su baze male ili imas previse rama - to kod tebe nije slucaj koliko vidim)
- datadir na XFS!!!
- zavisno od toga kakav ti data security treba podesavanje write barrier za xfs u odnosu na zahtev, binary logging etc etc
- query_cache, kreni sa malo (20-30M), pa polako podizi ako ti je dobar hit ratio, nemoj da kreces sa mnogo
- pogledaj tamo na mom blogu imas bitne informacije za podesavanje

tvoj my.cnd

1. old_passwords=1

To je nov app - izbaci to sr*nje koje sluzi da bi aplikacije pisane devedesetih i dalje radile, sada je 2011 godina!!!


2. innodb_flush_log_at_trx_commit=1
sync_binlog=1

jesi siguran? razmisli dobro sta hoces da ti pise ovde!!!
dalje, postavi binlog_format explicitno na vrednost koju hoces (mixed ili raw)


3. datadir=/var/lib/mysql
log-bin=/var/lib/mysql/mysql-bin.log

nemoj da drzis ova dva na istom fajl sistemu, ako ne moras (tj. ako ikako mozes baci ih na razlicite spindlove, razlicite particije na istom spindlu nisu neka velika prednost)

4. expire_logs_days = 4

da li vi u ta 4 dana napravite full bekap ?

bogi, fala. mene sredio neki virus, preležah par dana u krevetu, zato se nisam javljao.

2. innodb_flush_log_at_trx_commit=1 je default. je l ovo nije najbolji izbor za datu konfiguraciju? da stavim 0?
sync_binlog=1, e, da, ovo bi moglo na 0. Sve virtuelne mašine su na nekom storage-u, valjda imaju battery backup.
inače, nema replikacije ni na vidiku.

4. expire_logs_days = 4. to je njihova (firmina) vrednost. nek prave backup kad žele, ja samo mogu da ih upozorim na smisao ovog parametra i da provere s provajderom. osim toga, treba i mi nešto da radimo ;)

------------------
Sledeći parametri mi deluju interesantno (http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html)

a) innodb_commit_concurrency=1, da l ovo pomaže kod dead lock-ova?
b) innodb_concurrency_tickets=500 by default, ovo mi deluje previše u mom slučaju. Šta misliš da ga smanjim?
c) innodb_data_file_path=ibdata1:500M;ibdata2:50M:autoextend, da l da zveknem veći inicijalni ibdata1 fajl ili prvi veći + više manjih ili svi veći..? je l ima neke preporuke/pattern oko ovoga?
d) innodb_io_capacity, default=200. kakva su iskustva s ovim parametrom VM/storage kombinaciji?
e) innodb_log_file_size, ovo podsetnik za mene da malo uvećam, za sad, jer se valjaju i 100+ MB fajlovi kroz transakcije.
f) innodb_open_files, ovo treba usaglasiti s veličinom ibdata* fajlova
g) innodb_read_ahead_threshold=56 by default. ako bih redovno radio OPTIMIZE TABLE, ova parametar bi mogao da bude veći?
h) innodb_read_io_threads=4 by default, da l da povećam u ovoj VM/storage konfiguraciji?
i) innodb_use_native_aio, da l ima smisla da idem na native IO na CentOS-u?

ako ti nije jasno sta koja vrednost znaci - reci da razjasnim, ali sta ces da stavis zavisi samo od tebe. Tu ti je varijanta da li hoces 100% acid ili mozes da rizikujes zadnjih par transakcija ako rsne masina zarad mnogo boljih performansi



sta bre virtualno ?! nemoj mi pricas da teras mysql na virtualnoj masini, nemoj se zezas, stavi to na bare metal ako ti je bitan rdbms .. virtualne masine nemaju disk uopste, ignorise write barrier, ignorisu fsync etc etc ... ako se nedaj boze nesto dangne 99.9% dobijes koraptovanu datu u bazi ...

binlog moze da se koristi za point in time / incremental backup, ne samo za replikaciju ... isto kao i za flush_log.. ako nije jasno sta radi - reci da razjasnim, odluka dal ovo el ono je samo na tebi



zavisi, generalno ne bas, pomaze ako imas puno transakcija, dovoljno io-a i dovoljno cpu-a


default je ok



isti klinac ... ja na mysql only masinama turim odma ibdata da bude ogromantan i ne razmisljam o tome .. ide ono
- install os-a
- pravljenje jedne particije na spindlu za mysql datadir
- instaliranje mysql-a sa datadir-om na tom spindlu i ibd fajlom velicine cca 80% particije

zgodno kad to uradis na "svezoj" particiji posto ne brines o externom fragmentisanju samog fajla



default je ok. VM je problem, ne postoje parametri koji ce ti pomoci da resis to g...



optimize table sa innodb-om pravi tabelu "ispocetka", redovno teranje bas i nije preporucljivo



da se ne ponavljam, sve to nema nikakvog smisla na VM-u .. sve to sto ti siljis na VM-u, VM u 99% slucajeva samo ignorise, crash host masine u 99.9% slucajeva generise corupted data na vm masini, i to obicno tako da ne mozes da oporavis nista osim da vratis bekap. krsenje vm-a (vbox, vmware ..) u 90% slucajeva dovodi do koraptovane date ... krsenje os-a pod vm-om u 40-50% slucajeva dovodi do koraptovane date i krsenje mysql servera pod vm-om u 10-40% slucajeva dovodi do koraptovane data.... ako na to dodas marfija sve sto mogu da ti kazem je - ako ne poteras mysql na bare metal masini i treba da ostanes bez podataka

e, ovo g** od virusa ne pušta, ufff. ajd da razjasnimo šta je ostalo:

2. innodb_flush_log_at_trx_commit, ponovo probistrio InnoDB parametre i nije mi jasno šta mi nije jasno. je l treba da stavim 2 ako mislim da je VM fail-safe i to će da mi da superb performanse? ne mislim da su VMs fail-safe jer nemam nikakve informacije o njima osim da je CentOS. ubedio si me, nije mi jasno šta da setujem!

sync_binlog=1 i druge priče. VM-ovi su realnost trenutka koju ne mogu da promenim. ima 120-200 VM-ova i sam deployment je neka sasvim druga priča - VM je vrabac u ruci, fakat. Sad imam kompleksnu aplikaciju sa gomilom kratkih i povremeno dugim transakcijama po use-case-u. Polako je prepravljam, dok ne završim s tim (par meseci), treba mi fail-safe varijanta da se ne stresiram. Šta predlažeš?

------------
VM-ovi rade pod CentOS-om, nova verzija app će ići pod 6-com. Očekujem da je taj OS na visini zadatka - neće da pukne. Je l treba da znam, u vezi ovog, nešto što ne znam? I, kakav, bre, "crash host masine u 99.9% slucajeva generise corupted data na vm masini"? Je l se to dešava u praksi? Šta da radim da se to ne desi?

potpuno je nebitno sta ces da stavis posto ce VM svejedno da IGNORISE svaki sync koji mysql posalje, dakle ne postoji nacin da napravis VM da bude safe.




kada su baze podataka u pitanju, VM je govn. u ruci za koje jos ne znas koliko smrdi ... batali metafore ..




bare metal.
ili pravi bekap mysql-a na 10 minuta, tako mozes da izgubis samo 10 minuta vredno podataka




os je tu potpuno nebitan, svi oni "rade" ... crash host masine .. pa vidi, ja imam nedeljno po jednog koji je na kojekakvim amazonima i slicnim oblacima ostao bez podataka i place da mu pomognemo da vrati bilo sta od podataka, masine krasiraju, to je fakat, oni svi koriste neke super jeftine masine koje rade 24/7 i teraju xenove i slicne kalaku*cije i to puca, pucaju diskovi, puca memorija, pucaju cpu-i .. kapiras da su to masine non stop sa 100% zauzeca "svega" ... sta mislis dal se resetuju, freezuju etc etc .. naravno da da .. tebi je dovoljan jedan reboot masine da imas koraptovane podatke posto mysql kaze os-u "ovo sada mi STVARNO snimi na disk i nemo zezas" i os kaze "snimio sam" i mysql kapira da je to na disku i tera dalje ... sta se desi tebi je da to ne ode na disk posto VM iskulira ceo trip oko "snimi stvarno" i to kesira, masina se resetuje a posto sve te masine imaju ogromne keseve za disk jerbo bi umrle u roku od malopre na io load, sav taj kesh ode u /dev/null .... onda se masina resetne, sve kao radi, mysql krene da gleda sta je u tablespaceu a tamo NISTA ... neke gluposti .. nema log-a, nema komitovanih transakcija, nema gomile stvari ... kaze ti "sorry but jbga, ja ne znam sta s'ovo da radim, ako oces probaj rucno da povratis nesto od podataka" ...

pogledaj samo sta ti garantuje amazon kada uzmes oblak kod njih ..

Pozdrav,
da ne otvaram novu temu, pitanje vezano za virtualne masine, posto ni meni "ne gine" neki blade+vmware za poveliku bazu, zanima da li je kompromisno rjesenje odvojiti nekoliko fizickih diskova sa storage-a za tablespace i logfajlove te ih direktno mount-ovati na virt.masinu?

"povelika" baza i virtualna masina ... koji genije je to tako zamislio ..

evo ja treba da prevezem neke ormare, imam kamion ali sam izvadio motor i stavio pedale, da li ce da pomogne sad ako ja pedala vezem sa tockovima koristeci dupli lanac ?

Moj savet je sledeci

1. ako dizajnirate sistem, manite se virtualnih masina i baza podataka (za app i ostalo radite sta ocete to me ne zanima)
2. ako ste dobili izdizajniran sistem, onda tome ko je dizajnirao sistem sa VM-om dajte da dizajnira i bazu, nemojte prljati ruke sizifovskim poslom

u svakoj drugoj kombinaciji VI cete biti krivi zasto to ne radi, zasto radi sporo, i gde su podaci kada se baza koruptuje a ne onaj ko je rekao "mora vm".... ja sam imao par puta u zivotu priliku da gazda trazi X, ja mu kazem vidi X nece da radi, naje*aces, ostaces bez podataka ... a on odgovori sa, nema veze ja hocu X, ja placam i hocu X, i ja mu napravim X, desi se tacno sta sam rekao da ce se desiti i gazda poludi, a na "ali ja sam ti rekao da ces naje*ati i da to ne valja" dobijem odgovor - sto me nisi ubedio da ne idem sa X - TI si kriv" ... e posle par puta sam naucio, kazem NE MOZE X, ako oces X uradi sam ili nadji nekog drugog da ti uradi ... mene glava vise ne boli, a vi ako naucite nesto iz toga naucite, ako ne .. naucicete ima vremena, sto rece neko pametan, ucenje na tudjim greskama je utopija, srecan je onaj ko brzo nauci na svojim ...

Za neke vm sisteme restart u 100% slucajeva koruptira tabelu/bazu i za innodb se javlja masa gresaka u error logu tipa:

...............
Your database may be corrupt or you may have copied the InnoDB
..............

i jos puno toga sto ukazuje da innodb nije u redu.

Server se moze podici i innodb tablele su dostupne za SELECT (i samim tim za backup) preko innodb_force_recovery

U jednom takvom slucaju, innodb je proradio tek za innodb_force_recovery=4.

Medjtim, mysqldump mi je pucao a kako sam imao napravljen backup nekih 4h pre nego sto je server prso, jednostavno sam obrisao baze, innodb fajlove, startovao ponovo mysql i restorovao baze iz dumpa.

Sto se tice myisam tabela u slicnom slucaju na drugom serveru CHECK/REPAIR je odradio posao i myisam tabele su postale dostupne. Sada koliko su ti podaci bili aktuelni i sta je i da li je nesto od data bilo izgubljeno, nemam pojma ali se niko nije bunio :).

Inace i fizicke masine nisu 100% garancija da ce innodb biti siguran sto se tice transakcija ako sam OS/HW ne upisuje direktno na disk vec prvo puni neki svoj kes zbog brzine, performansi. Mislim da cak i na mysql.com ima preporuka da se iskljuci write hdd kes na linuxu ako HW dozvoljava to.

Pozdrav.

sa force recovery mozes da dodjes do podataka koji su ispravni, ne do "svih" podataka, dobar deo podataka prosto uopste nije snimljen na disk.


zato sto select nad koraptovanim podacima puca i sa force recovery. procedura za "Vadjenje" ispravih podataka je smor na kvadrat, generalno najbolje je da napises skript koji radi select red po red i belezi negde sa strane na kojim redovima je prso upit da imas log koje si redove izgubio ..



repair ce da napravi da tabela prolazi check tj da ti uradis select i dobijes datu, sta je u tabeli to niko ne zna, posebno posle VM crasheva ... vrlo je moguce da ce ti se pomesati podaci, da ce u nekim kolonama biti random podaci, da ces umest id, boja 7, crvena imati 11, crvena pa da ce integritet baze pokarambasiti kompletno i slicno ..



EXT4, XFS i jos neki file sistemi imaju nesto sto se zove write barrier. To sluzi da program bude siguran da je nesto upisao stvarno na disk. Savetuje se iskljucivanje write barrier samo ako imas battery backed up cache. Tako da - fizicke masine, ako umes da ih namestis, nude 100% garanciju. Fora je da imas dosta levela za "relaxiranje" sigurnosti i svaki taj nivo relaksacije daje malo na performansama te ti mozes da biras koliko ce podaci da budu sigurni. Problem je u tome da si ti sa VM-om ogranicen na "najrelaksiraniji" settings + malo gore od toga, a ne mozes da promenis nista po tom pitanju posto svaki nivo sigurnosti preko toga koji OS i MySQL nude VM ignorise.

Da se razumemo, ne postoji 100% sigurna stvar, mysql moze da koraptuje bazu nekim svojim bagom, da je sav hw ispravan .. uvek postoji ono "devine intervention" i te fore, ali ja ovde ne pricam o jedan u milion, pricam o stvarima koje se desavaju svakodnevno, mysql na vm-u je guranje ruke u vatru .. svakodnevno .... 100 dana ce da bude ok, 101 dan ces se opeci .. Da ne spominjem koliko puta se ljudima desi da im razni amazoni i ostali preveranti ladno ture 2 virtualne masine na ISTI hw (imao sam zadnjih 6 meseci 2 klijenta kojima je otisla baza a bili su u fazonu - nema veze ako prsne VM, ima replika na drugom, koja je sansa da prsnu obe) - prsla masina - ostali su bez SVIH podataka, jedan klijent je preziveo (lik koji je dizajnirao sistem je dobio otkaz, mysql dba je dobio otkaz i glavni developer je dobio otkaz!!) a drugi je bankrotirao... zadnjih 6 meseci je takodje bilo situacija da je ceo datacentar "stucno" i sve masine su se resetovale, necu ni sa spominjem kako je bilo na poslu tih dana ..

Da ponovim, ovo nije teoretski sta moze da se desi, ovo su stvari koje se desavaju svakodnevno ...

Naravno polako nastaju sistemi za baze podataka koje postaju otporne na ove probleme virtualnih masina, podaci se snimaju na 3-4 replike, nalaze rastrkani ... naravno sve to kosta mnogo, gubi se jednostavnost upita, gubi se referencijalni integritet, od ACID-a nema nista ... to sve vrlo ima smisla danas za aplikacije koje "mogu bez podataka", sta je fora, ako facebook danas ostane bez 1% podataka - nikom nista, ako google ostane bez 10% podataka - nikom nista ... ali ako jedan salesforce ostane bez 1% podataka - bankrotirace za 7 dana ... tako da ce salesforce da drzi web u cloud-u a podatke svojih korisnika na bare metal masini .. VM je odlicna stvar za mnooooooogo toga, razbijacka stvar, ultra turbo zgroz dobra stvar za mnogo toga, ali za RDBMS - to je pakao

Sada me malo razocaralo ovo za REPAIR/myisamcheck za MyISAM tabele :) jer mi se cinilo kao "magicna formula" bolje nego da vidim podatke iz dumpa koji kasni 24h.

Salim se malo.

Cini se da bi magicna formula bila; dobar HW, innodb, replikacija, i backup sa slave servera sto cesce.

Pozz.

MySQL 5.5 ili noviji
Semisinhrona replikacija (tako si siguran da je svaka transakcija otisla na slave)
Slave na LVM-u
mylvmbackup ko nema pare za MySQL Enterprise Backup a generalno moze i "shutdown slave-a, snapshot lvm-a, start slave-a, backup snapshota, brisanje snapshota" rucno da se uradi :) (to je inace moj omiljeni nacin bekapa) - bekap na trecu masinu (ja preferiram da povucem bekap u "centralu" sto je obicno neki noc ili nesto gde su dev masine, to iskopiras na neki externi disk i stavis na policu)

Tek odnedavno pratim ovaj forum, pa zelim da zahvalim Bogdanu na "surovoj" direktnosti u odgovorima, svaki post mu zlata vrijedi....
Nista, opet u raspravu sa menadzmentom i traziti "real hw"....

Kad smo vec u ovoj prici, kakva su (Bogdanova) iskustva sa SSD rjesenjima za storage, testovi pokazuju silne beneficije u performansama, ali da li su dovoljno "zreli" i sigurni? Ima li u praksi slucajeva da se SSD koriste u produkciji, na kriticnim sistemima?

SSD je vrlo nezgodna sprava za servere :( .. ja na jednom velikom sistemu gde pomazem privatno (inace presedan - morao sam da dobijem pismenu dozvolu jos u sun-u da bi mogao to da radim mimo firme) koristim ssd-ove u produkciji .. koristim ih na 2 razlicita tipa servera (ukupno nekih 10 servera, 8+2), na jednoj vrsti servera (8 komada) na ssd-ovima se vrti mysql koji je "skoro read only", dakle update nad bazom se radi samo jednom dnevno, sve ostalo vreme nad bazom idu samo upiti (ogromna baza, mnogo kompleksni neindexirani upiti) dakle skoro pa mozemo reci da je to read only sistem. Tu sede na svakom serveru po dva SSD-a u raid0 (stripe). Taj sistem je recimo 4-5 puta brzi od sistema koji je zamenio gde su bila 2 15kRPM SAS diska u raid0 (iako samo merenje read performansi nije uopste tako drasticno vece, ssd mozda ima 10% veci read speed, fora je u random access-u, tj seek time koji je na SSD 0 :D ) ... na tom "Read only" sistemu za 2 godine je crklo 2 ssd-a (od dakle 16 koji se koriste). Na ova druga dva servera se baza koristi "standardno" - dakle read write, i to je mnogo blize nekom enterprise koristenju nego nekom web-u, dakle ima 60% write i 40% read-a iz baze, jedan server je innodb, drugi je myisam, za 2 godine crkla su na jednom serveru 2 puta po jedan (uvek kada crkne jedan zamene se oba) i na drugom serveru jednom jedan (bas pre neki dan). Ubrzanje na ovim serverima (koji imaju write load od 60%) u odnosu na prethodnu varijantu sa 2x15kRPM SAS je neuporedivo ... razlika je 10000 puta .. ne moze da se izmeri .. serveri imaju po oko 1500 konekcija svaki koje drljaju neke hiljade tabela... u 2xSAS u raid0 server se tako zabode da obican ls -la cekas po 3-4 minuta, sa 2xssd u raid0 server radi bez ikakvog opterecenja, ne osetis da ga 1500 manijaka maltretira...

Svi serveri su vrlo "svesni" da mogu da ostanu bez podataka "u bilo kom trenutku" posto ssd nije, kao sto se da videti, neka slika i prilika sigurnosti. I na svim serverima je opterecenje 24/7 ..

Taj nivo "crkavanja" ssd-ova je otprilike i ono sto vidim kod klijenata, ima i baksuza (jednom klijentu je letos ako se dobro secam, za 2 meseca crklo za redom preko 10 ssd-ova u 2 servera) ... sada, meni recimo na ovom sistemu nije frka ako ostanem bez cele date, nista se strasno nece desiti, posto mi data svejedno zastareva svaki dan, ali recimo da mi je data bitna i da sam umesto raid0 stavio raid1 imao bi downtime kada su crkavali ovi ssd-ovi, ali nijednom nisu istovremeno ckrla oba, tako da ne bi bilo gubitka podataka ... dodatno, ovi moji ssd-ovi nisu neki "fancy" - to su ssd-ovi koje stavlja hosting provajder .. (niti znam koja marka ni koji model, ali sam siguran da ne stavljaju neke najkvalitetnije vec neki prosek)

Obratiti paznju da se polako pojavljuju RDBMS-i koji znaju sta je to SSD. Na primer za MySQL postoji poseban storage engine (ne pravimo ga mi, nije open source a mislim da nije ni dzabe) http://rethinkdb.com/ fora je da RDBMS koji je svestan SSD-a koristi SSD od pocetka do kraja. RethinkDB na primer pici po disku do kraja istog, ne brise nista sa njega, i tek kad stigne do kraja krene da pise od pocetka ... tako produzava vek diska... ako pak na primer stavis tmpdir na ssd ima da ga spalis dok si reko keks posto ces brisati i pisati po pocetku diska mnoooooooogo vise nego po kraju, na taj nacin ces brzo stici do onih "max writes" limita na pocetku diska i ceo disk ce biti za smece iako cela druga polovina diska nije ni naceta

Neki korisni linkovi:
http://mikaelronstrom.blogspot...-thoughts-how-to-make-use.html
http://www.slideshare.net/mats...eployment-strategies-for-mysql

da li ovo koruptiranje podataka u bazi koja je u virtualnoj mašini vrijedi za svaku bazu?

npr. oracle?

problem sa koraptiranjem podataka je vezan za svaki app koji se vrti na VM-u, i ms office koji se vrti na ms winblowsu koji se vrti u vm-u kada snimi svoj docx dokument taj isti mozda nece stici do diska ceo ...

oracle radi na svojoj virtualization platformi ( sto imaju svoje, sto su dobili sa sun-om, sto su kupili extra - radi sa na objedinjavanju svega toga, valjda to nije confidential info :D ) i oracle db ce sigurno umeti kroz taj vm da protera ono sto je bitno, obzirom da ce u nekom trenutku oracle db biti svestan tog vm-a ... mozda ce i mysql biti svestan istog, mozda ce, kako se siri prica sa oblacima i slicnim lelemudijama dovoljan broj izgubljenih podataka dovesti do nekog api-a koji ce vm davati aplikacijama koje "moraju da flushnu datu na disk" da mogu to i da odrade, i kojesta slicno pa ce mozda to vremenom postati sigurno ... danas, oracle db, ms sql, pgsql i svaki drugi db ima isti problem kao mysql, ti kazes operativnom sistemu / file sistemu da zelis da nesto bude zapisano na disk, ne u disk cache nego fizicki na magnet, vecina os/fs sistema daje mogucnost za to i rdbms to koristi, e sada, tu se danas prica koju rdbms moze da uradi zavrsava, VM taj zahtev ladno iskulira i to sto je rdbms zahtevao da bude zapisano na magnetni zapis - nije zapisano, dakle ako se VM resetuje - kadzbeng, baza je koraptovana. E sad, oracle db ima malo robusniji storage engine od mysql-a te ce oracledb lakse da se oporavi od koraptovane date nego myisam ili innodb-a ali to je sve u domenu "koliko imas srece" posto dubina septicke jame u kojoj ces se nalaziti posle krash-a vm host masine je toliko duboka da uglavnom samo polozaj zvezda moze da ti pomogne ...

čini mi se da ovu priču oko mysql-a na virtuelnim mašinama ne bi trebalo generalizovati, npr. za vmware-ove bare-metal hipervizore esx i esxi važi da ne keširaju upise gost OS-a: http://www.yellow-bricks.com/2...ythbusters-esxesxi-caching-io/ . sa hosted rešenjima tipa workstation je naravno drugačije, ali ne verujem da bi to iko normalan koristio za produkciju. ako imate drugačije iskustvo sa konkretno esx/esxi-em voleo bih da čujem, pošto se do sada nisam sretao sa ovim problemom.

pozdrav

esx nece izignorisati klasica fsync, ali ce ignorisati write barrier; to je znacajno bolje od toga da ignorise i fsync ali nedovoljno dobro za acid.

To sto momci kazu za esx/esxi uglavnom nije tacno (iako tvrde da ne rade kesiranje) .. sve i sa scsiX:Y.writeThrough = "TRUE" smo radili testiranja i nista ne ode direktno na disk iako je zahtevan zapis do magneta ... nece oni sigurno da javno napisu, cela ova kalakurcija oko virtuelnih masina je teska prevara ... nego polako resavaju probleme jedan po jedan a u medjuvremenu tesko baronisu sta se stvarno desava ... odnosno ovi koji ne znaju baronisu (ne)svesno a ovi ostali samo izvrcu istinu...

90% klijenata koji koriste virtualizaciju sa kojima sam ja pricaio su na esx(i). 10% na raznim drugim resenjima, u 2011 godini je bilo ukupno 2 klijenta sa korapcijom podataka koji nisu bili na VM-u i oko 250 komada koji su imali korapciju podataka a sede na vm-u. Ova dva klijenta na bare metalu su izgubili par slogova, od ovih 250 klijenata sa VM-a preko 200 je moralo da vraca bekap posto nista od baze nije moglo da se spase ..

Mozda (iskreno se nadam da nece) ce VM postati realnost, mozda ce oni sve ove probleme resiti (vrlo su ih svesni), mozda ce to jednom raditi onako kako su to zamislili i kako to reklamiraju, ali za sada je to jedna velika prevara.

da btw, imas komp kod kuce, uradis slobodno sam test. Ako imas paralelni port - jos bolje

napises app koji stuce par giga na disk, syncne ih i cim my sync vrati kontrolu ugasi napajanje kompa. Ja sam pravio elektroniku koja to radi tako sto puknem na par port cim zavrsim i procitam vamo sa parporta i prekinem napajanje. Onda kresnes masinu pa pogledas na sta ti lici FS i sta je od toga sto si pisao stvarno na disku. Uradis to 10tak puta, sa razlicitim velicinama upisa na disk... sa par razlicitih operativnih sistema i faj sistema i onda objavis rezultate. Ja moje "originalne" ne mogu da objavim posto su "internal documents" ali nije to neki veliki problem reprodukovati uz malo zice, par tranzistora i jednim releom.

Bogdane svaka čast na ovakvim detaljnim odgovorima bio mi je užitak čitati..

Ja sam tek početnik u svemu ovome,možeš li mi reći odakle najbolje početi što se tiče administracije MySQL server,Linuxa,clusteri itd ..imaš li preporuku za neku dobru knjigu ili sl.

Pozdrav

da li ste probali da testirate (ili da li neko od klijenata ima takvu konfiguraciju) sa vm ciji db disk je fizički RDM?

Kad vec svi merite, ja cu objaviti, ako dobijem dopustenje, neka merenja koja ja planiram da radim ovih dana... 2x 4-Core Xeon, 8GB RAM, 4xSAS 15krpm RAID 10. Planiram da testiram ext4 (sad se koristi), xfs (ja bi ovo), i zfs (ovo me kopka, na solarisu doduse...). Prvo sto me kopka je: Solaris 11 + ZFS + online kompresija. CPU vremena ima, ocekujem da bude brze jer se manje cita sa diska - ali pitanje je koliko.

Druga tema, koja me eventualno zanima - RAID 10, ili 2x RAID 1, pa na jedan array data, a na drugi indexi? Cini mi se da je ovo drugo gubljenje vremena, jer je baza fino indexirana, nema puno joinova, vecina upita je nad jednom jedinom tabelom, a i sve sto se pita je indexirano, pa nema neke potrebe za drljanjem data fajlova - pa mi se cini da je bolje da sve bude na istom array-u, koji je duplo brzi.

Da, uglavnom su MyISAM tabele u pitanju, mada planiram da neke tabele, probno, prebacim i na InnoDB, da uporedim razlike u performansama.

Na mom "drugom" blogu nevezanom za mysql ( http://elco.crsndoo.com/ ) imas sa desne strane moj amazon bookmarks (ne znam kako drugacije da ga linkujem), tu se nalaze sve knjige koje ja preporucujem.



Ako mislis na raw device mapping, tj da je disk na virtualnoj mapiran fizicki disk sa hosta - malo je takvih sistema - i na tim sistema jeste bilo koruptovanih podataka, doduse ja nisam pravio testove sa mapiranim diskovima zato sto minimalni procenat klijenata koji idu na virtualna resenja ima mogucnost za mapiranje fizickog diska, mapiranje fizickog diska uglavnom mozes samo na svom hw-u, a ako vec imas svoj hw onda si u glavnom dovoljno pametan da ga kupis tako da imas dedicated bare metal masinu za DB, hw je dovoljno jeftin danas da si to mozes priustiti .. kod device mappinga esx(i) ne radi uopste nikakvo kesiranje ali kao sto rekoh, ima problem sa write cache-om samo hw-a posto ne ume (tj bar nije umeo do pre par meseci, nisam proveravao od septembra) da ispostuje hw cache flush sa vm masine .. tu se moguci problem svodi samo na nestajanje podataka sa kesa kontrolera i kesa samog diska (sto je danas 16 ili 32 megabajta, sto uopste nije malo, posebno ako se tu nalazi metadata neke bitne tabele)

da zakljucim za mapirani disk - problem je mnogo manji ali je i dalje problem. Na hostovanom resenju je to skoro nemoguce dobiti, ako imas svoj hw onda nemas potrebu za virtualizacijom kada je rdbms u pitanju



svaki benchmark je dobrodosao.
1. napravi posebnu temu :D
2. dobro objasni kako si testirao, obavezno prilozi my.cnf
3. obavezno pored svojih testova uradi i test sa sysbench-om
4. raid 10 je brzi od raid1, po mojim testovima se ispostavilo brze raid0 pa indexi i data na njega nego bez raid-a na jedan disk data na drugi indexi, no kolege su imale druga merenja ... myisam je generalno prilicno mrtav tako da su svi podaci za njega stari mnogo godina. Ako ti ne trebaju informacije iz metadate tabele (tipa count(*) i slicno) i ako ti ne treba FTS myisam treba zaobilaziti osim ako ne znas bas sigurno sta radis (npr read only tabele i slicno).... jeste innodb i dalje sporiji za mnoge stvari, ali ako imas konkurentno pisanje po tabeli innodb je jedino resenje ..
5. koristi najnoviji 5.5, nemoj da na pragu 2012 godine pravis test sa deprecated verzijama mysql-a. Skini tgz verziju mysql-a sa dev.mysql.com NEMOJ da testiras sa beskorisnim binariem koji dolazi uz distribuciju
6. koristi nove tehnologije, ako imas velike tabele kojima se pristupa segmentisano, particionisi ih (i napravi merenje sa i bez particionisanja)
7. za cnf parametre za koje nisi siguran, napravi test sa raznim vrednostima, menjaj samo po jedan parametar :)

Vidio sam jos sinoc tvoje linkove u signature ,pa sam skontao taj amazon bookmarks ;) Hvala

Pozdrav

OK, rezlutati ako me puste, ali na zalost samo u obliku "upit 1", "upit 2" i sl - mada mogu da dodam i sysbench da optereti sa konkurentnim upitima, dobra je ideja. Radicu sa postojecom bazom, starom par godina, vecina je MyISAM, a InnoDB su samo tabele koje imaju konkurentne inserte, a za test ce ici upiti koji su inace spori. my.cnf cu probati da obajvim - s'tim da cu da iskljucim query cache, jer nicemu nece da sluzi - vrtecu upite tacno jednom. Naravno da ce ici 5.5 sa sajta, tako uvek stavljam :). Za particionisanje, videcu... Realno, ne vidim bas upotrebu, najcesce se pristupa samo indexima, a u retkim slucajevima kad ide drljanje po samim data tabelama skoro uvek se prodje kroz celu tabelu.

Cilj mi je, pre svega, odluka o fajl sistemu za buduce deploymente - i provera kako bi ZFS radio, tj. koliko bi ubrzanja donela file system kompresija, tako sto bi smanjila disk I/O.

Kazem, zavisi da li cu smeti da bilo sta objavim.... Videcu.

Jel ima sanse da ubacis i BTRFS u testiranje iako je jos uvijek beta?

ti bi se ladno usudio da turis butter na produkciju :D ludji si od mene :D

i ja bi voleo da vidim kakav efekat bi cow imao na rdbms sistem koji ga nije svestan ..

sto se zfs-a tice, pogledaj da li mozes da nadjes neke guide-ove za zfs i mysql, tweakovanjem zfs-a mozes mnogo toga da dobijes, ja ga licno ne trosim (imam doma neku spark masinu ali je starija od vecine ucesnika ovog foruma tako da nije bas reprezentativna za test) a kada imam pitanja vezano za zfs klijente bacam expertima za isti, ja na zalost o istom znam prilicno malo.. (nisam imao pojma da ima kompresiju, znam da ima dobru foru da moze da kesira fajl sistem na ssd diskovima i slicno ali nisam imao ideju da ima i kompresiju :D, to bi za myisam moglo dosta da promeni stvari na bolje, u teoriji )

Iskreno Tyler, nema. Ne vidim nikakvu poentu, meni treba informacija o tome sta je najbolje za produkciju - a btrfs nije na spisku necega sto bi stavio u produkciju. :)

Ja mislim da je to vrlo blizu neke produkcije sto se tice konacnih performansi, i mislim da ce do kraja vecina koda da se svede na peglanje bugova i dodavanje nekih manjih mogucnosti. Pa kad se vec radi test nekoliko fajlsistema, jos jedan FS vise manje nije problem.
Naravno, ne mislim da se to stavi u produkciju, ali kada se vec radi testiranje mislim da bi info o btrfs dobro dosao u svakom slucaju, bar kao neka referenca za buducnost.

Inace, ja koristim btrfs na 2 masine koje nisu kriticne vec par mjeseci sigurno...

A na cemu ces ZFS da testiras? Solaris?

Odosmo u offtopic. Mozda bi valjalo da mod ovo premjesti u novu temu...

ZFS može da se testira na FreeBSD-u: 8.2 podržava ZFS 15, 9.0 (koji je već negde oko RC) podržava ZFS 28; posebnu pažnju obratiti na poboljšanje performansi kada se koristi Intention Log (ZIL) za upis, i Cache Device, za čitanje.

Pošto FS nudi live snapshot, checksumming i još kilo džirlo-klagenfurfera, mislim da bi bio sjajan za test - ostaje samo pitanje koliko je brz za baze.

...valjda nije samo offtopic, nego malo i hint ;)

-----------
ja trenutno rabim u špajzu jedan raidz od 7x maxtor 80, i kingston fleš kao keš drajv - i nemam ozbiljan zadatak za tu mašinu, jer služi samo kao bekap - rsync i slično, i malo fajl server za po kući.

ako se dobro secam zfs nema sve opcije na bsd-u koje ima na solarisu, mislim da bi, ako se vec testira fs, najbolje bilo uraditi test zfs-a u prirodnom okruzenju (solaris)

Bogdane a ReiserFS? probao nesto s njim da petljas? tipa gasenje na zivo,korupcija baze i slicne zaebancije? Iako je malo ispao iz price od kad je tvorac istog ubio zenu , radi zaista perfektno.

nisam probao nikad da teram mysql na reiserFS-u. Terao sam reiser uglavnom kao fs za razne proxy-e i slicno ali kad su ga smestili u tvorza XFS je vec stao na noge tako da sam se ja prebacio... inace sam koristio XFS jos na silikon grafiksima tako da cim je postao dostupan na lindzi ja sam se prebacio .... nemam ideju kakvo je sada stanje sa reiserom, ni dal je covek i dalje u tvorza ili je izasao, dal je u tvorza pisao taj fs ili nije .. kapiram da je tamo imao puno slobodnog vremena ...