Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Podešavanje MySQL 5.5 u produkciji

[es] :: MySQL :: Podešavanje MySQL 5.5 u produkciji

Strane: 1 2

[ Pregleda: 5794 | Odgovora: 32 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

bjevta
Bratislav Jevtic
http://www.tojesoft.co.rs
Kragujevac

Član broj: 5216
Poruke: 365
*.dynamic.sbb.rs.

Sajt: www.tojesoft.co.rs


Profil

icon Podešavanje MySQL 5.5 u produkciji09.11.2011. u 21:33 - pre 1076 dana i 23h

imaću u najskorije vreme nešto CentOS 6 virtuelnih servera sa MySQL-om. Ukupna memorija servera je ili 4GB ili 8GB. Na serverima se, osim MySQL-a, izvršavaju Tomcat i barem 3 aplikacije pisane u njemu. Java<->MySQL je preko Hibernate-a.

Baze:
1. prva, koja se non-stop koristi, ima 300+ MB, ne verujem da prelazi 1GB ni u jednoj varijanti.
2. druga, repozitorijum za dokumente, 6GB+, pristupa se stalno ali ne baš non-stop.
3. treća, veoma mala ali se non-stop vrte extra prosti upiti po njoj. predlagao sam embeeded bazu al' mi to, za sad, nije prošlo.

Broj korisnika je, otprilike, do 1500 od kojih je nekoliko desetina non-stop na aplikaciji i radi projekt menadžement (prati šta ima novo, vrti par uber komlikovanih select upita nad najvećim tabelama). Ostali se zakače, odrade i odjave. Ili, većina startuje browser i tako stoji, pa im browser refreshuje svakih nekoliko sekundi. Ovi use-case-ovi mi nisu jasni al, ajd da pretpostavimo ovaj drugi - da su svi stalno online.

Connection pool C3P0 otvara do 120 konekcija, provereno sasvim dovoljno.

E, sad trebaju mi preporuke za podešavanje MySQL-a. Osnovne stvari znam, trebaju mi tips'n'tricks. Bitniji mi je princip razmišljanja i na šta da obratim pažnju nego same cifre:
- da l da isključim binarni log i koliko bih dobio na performansama,
- koji parametri su bitni tako da se odradi najbolja moguća sprega sa CentOS-om
- ima li neki štos koji treba znati u vezi CentOS-a ili Linux-a, an ženeral, da sa MySQL-om zajedno radi što bolje? na primer, tmp folder može da ide u ram, ako se dobro sećam? za detalje Linux-a imam lika u firmi, problem je što ne znam šta da ga pitam.
- myisam parametri, trebaju mi za virtuelne tabele (valjda?). kako da njih uparim? trenutno aplikacija dosta pravi neke JOIN-ove i sl. pa bih olabavio RAM za temporary tabele.
- kako da definišem parametre za keširanje upita_

Evo nekih mojih razmišljanja u vezi MySQL-a (my.ini):
- innodb_additional_buffer_size bih postavio na 512 MB za 4GB RAM server, 1GB za 8GB RAM server.
- broj konekcija do 150

Već ostavljao ovde tekuću verziju my.cnf-a:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
server-id=22199
innodb_flush_log_at_trx_commit=1
sync_binlog=1
log-bin=/var/lib/mysql/mysql-bin.log
expire_logs_days = 4
tmpdir=/tmp

## Requested by Xavier Fort 7/29/2011
max_allowed_packet=16M
#max_connections=250
character_set_client=utf8
#character_set_connection=utf8 #invalid entry
#character_set_database=utf8 #invalid entry
character_set_filesystem=binary
#character_set_results=utf8 #invalid entry
character_set_server=utf8
#character_set_system=utf8 #invalid entry
#collation_connection=utf8_unicode_ci #invalid entry
#collation_database=utf8_unicode_ci #invalid entry
collation_server=utf8_unicode_ci
#table_type=innodb #invalid entry

## Requested by Marko Jevtovic 8/16/2011
innodb_buffer_pool_size=512M
innodb_thread_concurrency=10
innodb_additional_mem_pool_size=4M
tmp_table_size=32M
max_connections=120
default-storage-engine=innodb
default-character-set=utf8

## Added by Eric Okumura 9/2/2011
transaction-isolation=REPEATABLE-READ
Acta, non verba!
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.41.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji09.11.2011. u 22:05 - pre 1076 dana i 23h
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 ?


 
Odgovor na temu

bjevta
Bratislav Jevtic
http://www.tojesoft.co.rs
Kragujevac

Član broj: 5216
Poruke: 365
*.dynamic.sbb.rs.

Sajt: www.tojesoft.co.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji12.11.2011. u 18:21 - pre 1074 dana i 3h
Laptopovi

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?





Acta, non verba!
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.41.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji13.11.2011. u 06:39 - pre 1073 dana i 14h
Citat:
bjevta
2. innodb_flush_log_at_trx_commit=1 je default. je l ovo nije najbolji izbor za datu konfiguraciju? da stavim 0?


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

Citat:
bjevta:
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.


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

Citat:
bjevta:
a) innodb_commit_concurrency=1, da l ovo pomaže kod dead lock-ova?


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

Citat:
bjevta:
b) innodb_concurrency_tickets=500 by default, ovo mi deluje previše u mom slučaju. Šta misliš da ga smanjim?

default je ok

Citat:
bjevta:
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?


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

Citat:
bjevta:
d) innodb_io_capacity, default=200. kakva su iskustva s ovim parametrom VM/storage kombinaciji?


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

Citat:
bjevta:
g) innodb_read_ahead_threshold=56 by default. ako bih redovno radio OPTIMIZE TABLE, ova parametar bi mogao da bude veći?


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

Citat:
bjevta:
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?


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
 
Odgovor na temu

bjevta
Bratislav Jevtic
http://www.tojesoft.co.rs
Kragujevac

Član broj: 5216
Poruke: 365
*.dynamic.sbb.rs.

Sajt: www.tojesoft.co.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji15.11.2011. u 08:16 - pre 1071 dana i 13h
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?




Acta, non verba!
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.41.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji15.11.2011. u 08:39 - pre 1071 dana i 12h
Citat:
bjevta:
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!


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.


Citat:
bjevta:VM je vrabac u ruci, fakat


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


Citat:
bjevta: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š?


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


Citat:
bjevta:
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?


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 ..

 
Odgovor na temu

farmaceut
Apoteka
Banja Luka

Član broj: 182739
Poruke: 46
188.124.197.*



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji19.11.2011. u 18:34 - pre 1067 dana i 2h
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?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji19.11.2011. u 22:56 - pre 1066 dana i 22h
Citat:
farmaceut: 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 ...
 
Odgovor na temu

after
Ajvanho, ING

Član broj: 276962
Poruke: 94
*.dynamic.sbb.rs.



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 09:46 - pre 1066 dana i 11h
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.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 10:07 - pre 1066 dana i 11h
Citat:

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


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

Citat:

Medjtim, mysqldump mi je pucao

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 ..

Citat:

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 :).


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 ..

Citat:

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.


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
 
Odgovor na temu

after
Ajvanho, ING

Član broj: 276962
Poruke: 94
*.dynamic.sbb.rs.



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 10:30 - pre 1066 dana i 11h
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.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 10:35 - pre 1066 dana i 10h
Citat:
after
Cini se da bi magicna formula bila; dobar HW, innodb, replikacija, i backup sa slave servera sto cesce.


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)

 
Odgovor na temu

farmaceut
Apoteka
Banja Luka

Član broj: 182739
Poruke: 46
188.124.197.*



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 10:46 - pre 1066 dana i 10h
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?
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 11:13 - pre 1066 dana i 10h
Citat:
farmaceut
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

 
Odgovor na temu

MarkoBalkan

Član broj: 141124
Poruke: 1624
178.160.14.*



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 13:49 - pre 1066 dana i 7h
da li ovo koruptiranje podataka u bazi koja je u virtualnoj mašini vrijedi za svaku bazu?

npr. oracle?

 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 16:07 - pre 1066 dana i 5h
Citat:
MarkoBalkan: 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 ...
 
Odgovor na temu

borkowski

Član broj: 290869
Poruke: 33
*.adsl-a-7.sezampro.rs.



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji20.11.2011. u 22:46 - pre 1065 dana i 22h
č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
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji21.11.2011. u 00:00 - pre 1065 dana i 21h
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.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
MySQL Cluster Engineer
Oracle
srbistan

Član broj: 201406
Poruke: 10926
95.180.61.*

Sajt: mysql.rs


Profil

icon Re: Podešavanje MySQL 5.5 u produkciji21.11.2011. u 00:05 - pre 1065 dana i 21h
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.
 
Odgovor na temu

IcemanX
Fakultet informacionih tehnologija
Beograd

Član broj: 253997
Poruke: 154
*.dynamic.sbb.rs.



Profil

icon Re: Podešavanje MySQL 5.5 u produkciji21.11.2011. u 02:48 - pre 1065 dana i 18h
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
alea iacta est
 
Odgovor na temu

[es] :: MySQL :: Podešavanje MySQL 5.5 u produkciji

Strane: 1 2

[ Pregleda: 5794 | Odgovora: 32 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.