[es] - InnoDB > MyISAM replikacija

Shinhan
PHP programmer
Subotica

Član broj: 12327
Poruke: 372
91.150.127.*

Jabber: shinhan@elitesecurity.org
ICQ: 400847988

+4 Profil

InnoDB > MyISAM replikacija

^{20.03.2009. u 08:22 - pre 183 meseci}

Gledajući MySQL dokumentaciju, kolega je primetio članak o InnoDB -> MyISAM replikaciji. To jest, master i slave tabela ne moraju da koriste isti engine.
Trenutno imamo jedan MySQL server i jedan web server, i pošto nam je sad SQL usko grlo mislimo da uzmemo još jedan MySQL server i od njega napravimo slave. Glavni sql server ima tri baze (za isti sajt, vrlo čudno, nismo to mi smislili) i otprilike pola tabela su InnoDB a pola MyISAM. Koliko bi bila dobra ideja da slave bude čisto myisam? Koliko vidim na masteru innodb tabele nemaju foreign key pa to ne bi trebalo da je problem.

"Common sense is not so common." - Voltaire

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: InnoDB > MyISAM replikacija

^{20.03.2009. u 11:54 - pre 183 meseci}

Citat:

To jest, master i slave tabela ne moraju da koriste isti engine.

yup, vrlo cest setup... cesto ces videti blackhole -> (myisam|innodb) ... koristi se za cuvanje podataka koji nisu potrebni na master serveru ..

Citat:

Koliko bi bila dobra ideja da slave bude čisto myisam? Koliko vidim na masteru innodb tabele nemaju foreign key pa to ne bi trebalo da je problem.

strani kljucevi nisu nikakav problem, sve i da ih ima, a sto se tice samo slave-a ... bilo bi ok da ceo slave bude myisam posto samo jedan thread radi upis (slave thread), svi ostali threadovi rade samo citanje (jeli, to je read only server - slave) tako da to sto myisam radi table lock ne utice na performanse, mnogo je lakse / brze odraditi bekap myisam tabela (savetujem ti da montiras taj mysql na LVM - zbog "jos lakseg bekapa")...

obrati samo paznju
- ako koristis 5.0, on ima samo SBR i to nije safe "uvek" .. dakle ako imas upite tipa (insert into select from ) takvi upiti mogu da zabodu SBR
- ako koristis 5.1 on ima i SBR i RBR i MIXED ... nemoj da se oslanjas na "default" vrednost vec setuje binlog type na ono sto hoces. ja predlazem MIXED za pocetak.

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

Odgovor na temu

Shinhan
PHP programmer
Subotica

Član broj: 12327
Poruke: 372
91.150.127.*

Jabber: shinhan@elitesecurity.org
ICQ: 400847988

+4 Profil

Re: InnoDB > MyISAM replikacija

^{23.03.2009. u 07:19 - pre 183 meseci}

E sad, što se tiče O_DIRECT. Koliko sam ja primetio na testovima performansi uvek uključuju to, a u dokumentaciji piše da se to treba koristiti samo kod Battery Backed-Up RAID. Međutim, mi uopšte nemamo RAID. Da li bi (i koliko) gubili na sigurnosti podataka ako bi uključili O_DIRECT?

Dalje, da li možemo staviti da slave bude 5.1 dok master ostaje 5.0?

I jedno query pitanje.
Glavna tabela na ovom sajtu koji optimizujem ima polje "status". Koje je numeričko ali se koristi kao ENUM. Svi upiti nad dotičnom tabelom imaju kao jedan od parametara i "WHERE status NOT IN (1,2,4,7)" ili tako nešto. Pola statusa su razne varijante "aktivan" a pola "neaktivan". E sad, čitam ja da je "IN" dosta spor, ali da li bi "NOT FIND_IN_SET(status,"1,2,4,7")" bilo brže? Takođe pošto aktivni i neaktivni statusi nisu lepo skupljeni ne mogu da radim "WHERE status < 0" (eh što nisu neaktivnim statusima davali negativne vrednosti a aktivnim pozitivne).

"Common sense is not so common." - Voltaire

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: InnoDB > MyISAM replikacija

^{23.03.2009. u 08:20 - pre 183 meseci}

Citat:

Shinhan: E sad, što se tiče O_DIRECT.

O_DIRECT je "vrlo komplikovan".... generalno, O_DIRECT radi direkt DMA disk-ram-disk .. e sada, ima kernel bagova sa o_direct tako da obrati paznju ...

Citat:

Koliko sam ja primetio na testovima performansi uvek uključuju to

naravno, to je bitan info za performanse... posebno sto u nekim slucajevima (na primer ako koristis SAN storage) usporava drasticno SELECT

Citat:

a u dokumentaciji piše da se to treba koristiti samo kod Battery Backed-Up RAID

mislim da si nesto pomesao ... innodb_flush_log_at_trx_commit i sync_binlog imaju veze sa keshom i to nije bitno da li je RAID ili ne, prica se o cache kontroleru....

Citat:

Međutim, mi uopšte nemamo RAID. Da li bi (i koliko) gubili na sigurnosti podataka ako bi uključili O_DIRECT?

ne, o_direct moze samo da poveca sigurnost podataka, nikako da smanji

Citat:

Dalje, da li možemo staviti da slave bude 5.1 dok master ostaje 5.0?

da osim ako nemate neke stvari koje su nekompatibilne ... pogledaj spisak nekompatibilnih promena u 5.1
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html

Citat:

Glavna tabela na ovom sajtu koji optimizujem ima polje "status". Koje je numeričko ali se koristi kao ENUM. Svi upiti nad dotičnom tabelom imaju kao jedan od parametara i "WHERE status NOT IN (1,2,4,7)" ili tako nešto. Pola statusa su razne varijante "aktivan" a pola "neaktivan". E sad, čitam ja da je "IN" dosta spor, ali da li bi "NOT FIND_IN_SET(status,"1,2,4,7")" bilo brže? Takođe pošto aktivni i neaktivni statusi nisu lepo skupljeni ne mogu da radim "WHERE status < 0" (eh što nisu neaktivnim statusima davali negativne vrednosti a aktivnim pozitivne).

FIND_IN_SET i IN koriste isti execution path tako da ti ta promena ne bi donela nista ... ako u IN imas nekoliko vrednosti onda je to ok i nije mnogo sporo (kao da si napisao where status=1 or status=2 ..)

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

Odgovor na temu