Hol fusson a Mysql ?

Fórumok

Hi !

Van (lessz) egy apache2 szerver mysqlel, phpmyadminnal.
Ez 1 vserveren fog futni.
A mysql hogy fut biztonságossabban?
1.) A vserver hoston és csak a socketet adom az apacsos vservernek ?
2.) Csinálok neki 1 külön vservert a belső virtuális hálóra, és kiteszem annak az ip-jére, ahonnan eléri a másik szerver ?
3.) Ugyanazon fut mint az apacs ?
4.) Tökmind1

Thx :)

Hozzászólások

socketes elérés mintha gyorsabb lenne, mint a tcp kapcsolaton keresztuli kommunikacio.
amugy 4.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

4 csak rendesen meg kell csinálni és nem összehányni

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam.

debian 4.0 - linux-2.6.22-rc7-wifi0 - 2.6.22-rc7 kernel madwifivel itt

En az 1-re szavazok.

ASK Me No Questions, I'll Tell You No Lies

Szerintem meg a zapache-ot vagy mod_security-val vagy máshogy chrootold. A mysql pedig gyárilag tud chrootot már.
Ha localhoston vannak, akkor pedig tcp-vel is tudnak jól kommunikálni.

A libmysqlclient, ha localhoston van es socket eleres lehetseges, akkor nemigen tudod tcp-re kenyszeriteni. Valamiert, ha erzi, h azonos hoston fut, akkor socketet kenyszeriti. Nemtom ez hol dokumentalt behavior es hogy hogy lehet megkerulni.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

"Hol fusson a Mysql ?"

Ne forró zsírban! :D

Sztem 4.
ill nyóc.
----------------------------------------------------------------

Ugyan nem annyira biztonsagi, mint megbizhatosagi kerdes, de szerintem lenyeges, hogy ne kozos memoriaban fussanak.

Mind a kettonek van hajlama forkolni mint egy okor. Aztan elfogyasztjak egymas elol a memoriat.
Ez persze nagy terhelesnel esik meg. Csak hat "az interneten" nem annyira te szabalyozod mennyire terhelik meg a szerveredet.

Kedvenc jelenetem:
1. Nincs epeszu MaxClients az apacheon.
2. bejon majom es szetbombazza az indian agyat 2000req/mp-cel egy jo kis dinamikus oldalra.
3. Apache forkol, SQL forkol, fogy a memoria,
4. elerik a pontot amikor elkezdunk swappelni
5. mysql elkezd torlodni mert allandoan diszkrol kell neki minden olvasnia. Meg az aktiv memoriajat is :)
6. apache-ok elkezdenek torlodni, mert az SQL-re varnak.

S igen lattam mar ilyet. A sajat szervereimen :)
S ez meg nem is jatszik a diszk I/O-val. Ott is tudnak versenyezni.
Jon be a sok insert/update az SQL-be mikozben az apache meg error/access logol. Ez is tud okosakat eloallitani.

Biztonsagi szempontbol gondold vegig...
Az apache-ban fut egy alkalmazas ami hozzafer az adatbazishoz? Innentol mennyire szamit, hol van az az SQL peldany? Ugyis ott van a webszerveren az osszes szukseges hozzaferesi parameter. De meg erre sem feltetlenul van szuksege, csak egy jo kis bugos PHP scriptre a szerveren.

Jol hangzik, de mennyivel jobb az, hogy

A) 1 gep (1G RAM, 1GHz) spache + 1 gep (1G RAM, 1GHz) mysql
mint
B) 1 gep (2G RAM, 2GHz) apache+mysql

Mert ha A-nal a mysql elkezd nem (ill. lassan) valaszolni, az apache processzek
ugyanugy varnak sql-re. Imho a B) is jarhato, ha korrekt eroforras limiteket
allitasz be: max. ennyi meg ennyi kerest engedunk a apache/mysql fele, a tobbit
meg eldobjuk, vagy queue-ba tesszuk.

ASK Me No Questions, I'll Tell You No Lies

Arról nem beszélve, hogy így a Disk I/O konfliktus elkerülődik.
Mondjuk én a lehetőségekhez mérten mindenképp külön tenném, mert így sem memóriában sem a lemezen nem kell osztozkodniuk, így effektív kissebb a konfliktus esélye.

Persze a weboldal SQL szkriptjeit sosem árt leellenőrizni, vannak Apach stress testek dögivel.

Arrol nem is beszelve, hogy ma egyre nagyobb divat a virtualizacio, ahol van egy nagy teljesitmenyu vasad, es azon hozol letre virtualis gepeket (amelyek valojaban ugyanazt a memoriat - meg a tobbi eroforrast - eszik, ok ennel komplexebb azert a dolog).

ASK Me No Questions, I'll Tell You No Lies

3.) lett belőle az 1szerűség kedvéért :)

Szerk.: ja, latom, mar eldolt.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!