Miten luotettava mySQL todellisuudessa on?
Tiedän että se ei kokonaan täytä ACID-kriteerejä, mutta ottaen huomioon hintaero sen ja esim. Oraclen välillä, mietin miten vaativia sovelluksia siihen uskaltaa laittaa.
Jos tietokannalla on ainoastaan yksi käyttäjä kerrallaan, virhemahdollisuudet ovat käsitykseni mukaan pienemmät?
Mikä näistä sovellusesimerkeistä ette laittaisi mySQL:ään (ja miksi ei?) (oletetaan että tiedot koskevat keskisuurta yritystä)
- henkilöstörekisteri
- laiterekisteri
- asiakasrekisteri
- työajan seuranta (tuntikirjaus)
- palkanlaskenta
- kirjanpito
- muu??
mySQL
turvallisuus
13
1182
Vastaukset
- Joo255
Eikos Oraclesta ole saatavilla joku ilmaisversio?
Riittäisikö se, samaten MS-SQL serveristä on myös ilmaisversio.
Vilkaiseppas http://www.postgresql.org/ muistaakseni tuo täytti ACID-kriteerit, joskin hitaampa kanta kuin MySQL, mutta se ei sinua haita kun yks kerrallaan käyttää.
"Mikä näistä sovellusesimerkeistä ette laittaisi mySQL:ään (ja miksi ei?) (oletetaan että tiedot koskevat keskisuurta yritystä)"
Voi nuo kaik laittaa MySQL kunhan serveriin kiinnitetään huomiota, ja löytyy UPSeja jolloin sähkökatkotkaan ei aiheuta ongelmia. - ..............................
Mun mielestä se on riittävän turvallinen.
Siinä on pitkään kehitetty ja testattu suojajärjestelmä, access-rightsit toimii aivan oikeasti.
Se kuinka turvallinen tietokanta on riippuu aivan täysin siitä kuinka tietoturvallisesti tietokantaa käyttäviä ohjelmistoja on kehitetty ja millainen on tietokantaserverin tietoturva...
Tietokanta erillisellä palvelimella serverihuoneessa, kyseiseen palvelimeen pääsee VAIN JA AINOASTAAN ohjelmistoserverikoneilta, kaiken muun kommunikaation estää palomuuri. Tällöin suora tietokantaan murtautuminen on huono lähestymistapa.
Ohjelmistot sitten kehitetään käyttäjäroolien kanssa ja tietokantataulujen grantteja jaetaan vain todellisen käyttötarpeen mukaan ja "GRANT *":a ei anneta kenellekään paitsi tietenkin sille joka tietokantaa ihan oikeasti saa hallita. Sillä kuinka monta käyttäjää systeemissä on ei ole merkityksekästä; jos koodi on sutta niin yhdelläkin käyttäjätunnuksella voi tehdä rajattomasti pahaa. (GRANT * - tilanne).
Sitten loppu onkin asiakasohjelmistojen koodaajien tietotaidon armoilla. Jos koodaajat ovat lepsuja ja mahdollistavat koodeissan sql injectionin niin se ei ole enää tietokannan ongelma. Näitä vastaan tietenkin voi tehdä erilaisia auktorisointirutiineja tai poikkeama-auditointeja mutta ne ovatkin asioita jotka indikoivat sen että kakka on housussa, eivät suinkaan kiristä sulkijalihasta ajoissa... Toisaalta esim. palkanlaskennassa yms nää auditoinnit olisivat kyllä ihan hyvä tapa saada kiinni virheitä muutenkin.
mySQL:lle on täysin mahdollista tehdä kovan turvaluokituksen koodia. Se on kyllä järjestlemänä tarpeeksi eheä koodillisesti.
Näköjään mukana ei ollut avoimia internet-sovelluksia, silloin tietoturvariskit vähenee. Internet-sovellusten kohdalla käyttäisin kahden sql-palvelimen taktiikkaa jolloin nettiin päin näkyvät systeemit päivitettäisiin batcheinä sisään-ulos eli siis tietovarannot olisivat fyysisesti erillään tuotannossa ja "julkisivussa". tällöin toisen systeemin saastuminen ei koskettaisi tärkeitä sisäisiä järjestelmiä vaan jäisi pintavaurioksi ja replikoidun korvattavan datan kanssa rälläämiseksi. Hintanahan olisi todellisen reaaliaikaisuuden puute mutta se on pieni hinta.- .........................
Ja niiden kriteerien puuttuminen saattaa johtua siitä etteivät My:n kehittäjät halua maksaa megataaloja auditoinnista vaikka järjestelmä itsessään täyttäisi kirkkaasti kriteerit.
- --------
Eikös tässä ollut kysymyksessä kuinka luotettava MySQL on, ei siis varsinaisesta tietoturvasta?
Siis mitä tapahtuu jos kantaan syötetään dataa ja kanta kaatuu juuri silloin jne...
Ei siinä tietoturvajutut auta jos tärkeä pankkisiirto katoaa kannan kaatumisen seurauksena. - zxcvbnm
-------- kirjoitti:
Eikös tässä ollut kysymyksessä kuinka luotettava MySQL on, ei siis varsinaisesta tietoturvasta?
Siis mitä tapahtuu jos kantaan syötetään dataa ja kanta kaatuu juuri silloin jne...
Ei siinä tietoturvajutut auta jos tärkeä pankkisiirto katoaa kannan kaatumisen seurauksena.Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla.
- --------
zxcvbnm kirjoitti:
Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla.
"Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla."
Mutta eivät transactiot auta jos tietokanta kaatuu jne... suurempaa tapahtuu juuri oikealla hetkellä. Transactiot ovat sitä varten jos jostain syystä joku kysely epäonnistuu niin silloin osaa peruttaa toiminnon, mutta tietokannan täytyy olla silloin pystyssä ja muutenkin toimia silloin kunnolla. - ..............................
-------- kirjoitti:
"Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla."
Mutta eivät transactiot auta jos tietokanta kaatuu jne... suurempaa tapahtuu juuri oikealla hetkellä. Transactiot ovat sitä varten jos jostain syystä joku kysely epäonnistuu niin silloin osaa peruttaa toiminnon, mutta tietokannan täytyy olla silloin pystyssä ja muutenkin toimia silloin kunnolla.""Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla."
Mutta eivät transactiot auta jos tietokanta kaatuu jne... suurempaa tapahtuu juuri oikealla hetkellä. Transactiot ovat sitä varten jos jostain syystä joku kysely epäonnistuu niin silloin osaa peruttaa toiminnon, mutta tietokannan täytyy olla silloin pystyssä ja muutenkin toimia silloin kunnolla."
Tuota. Ei siinä millään kannalla ole jakoja jos kanta kaatuu kesken operaation; silloin ongelma on sovellustekninen; sovelluksen on pystyttävä varmistamaan/olemaan vakuuttunut onko tieto varmasti persistenttinä sisässä.
Kysymykseen tulevat sitten sellaiset asiat kuin Myslin writecache, veikkaisin että se on mahdollista pakottaa eli siis mysli huolehtii että tieto puristetaan levypinnalle ennenkuin palautetaan onnistunut operaatio. Tällöin tiedon persistenssi voidaan sovelluksessa todentaa siitä että paluuarvo tulee. Hidastaa kantaa (koska writecachea ei voi käyttää) mutta silloin tietokanta ei koskaan anna ei-ajantasalla olevaa tietoa persistenssistä takuuvarmasti. Jos kanta kaatuu keskenään niin paluuarvoa ei luonnollisesti tule ja ohjelmiston on huomattava se taas itsekseen ja osattava tarjota erroria.
Toisin sanoen, pakottamalla levykirjoitus taataan että onnistunut operaatio pysyy persistenttinä vaikka kanta kaatuisi millisekuntia myöhemmin.
Siitä eteenpäin ongelma on tietovarannon rakenteesta (raidauksista yms), ei myslistä.
Huvikseni etsin asiasta...
------------------------------
Disable flush transaction on commit
When using InnoDB, by default MySQL flushes data to disk when transactions are commited. This means that each transaction is flushed to disk when it occurs. This provides data security in case the database server crashes.
The default behaviour can be overridden with the following setting:
innodb_flush_log_at_trx_commit = 0
This setting makes MySQL flush the transaction cache every second instead of after each commit. This means transactions are not flushed to disk the moment they happen. While this improves performance, you must decide whether the risk of losing data due to a server crash is acceptable.
-----------------------
MyISAM:eissa transaktiot ovat siis dataturvallisia, mutta suorituskykyä parantaakseen ne saa erikseen konfattua pois päältä.
Vastasiko kysymykseen? - --------
.............................. kirjoitti:
""Kyllähän nuo asiat hoidetaan Myslissä kuten muissakin transactiolla."
Mutta eivät transactiot auta jos tietokanta kaatuu jne... suurempaa tapahtuu juuri oikealla hetkellä. Transactiot ovat sitä varten jos jostain syystä joku kysely epäonnistuu niin silloin osaa peruttaa toiminnon, mutta tietokannan täytyy olla silloin pystyssä ja muutenkin toimia silloin kunnolla."
Tuota. Ei siinä millään kannalla ole jakoja jos kanta kaatuu kesken operaation; silloin ongelma on sovellustekninen; sovelluksen on pystyttävä varmistamaan/olemaan vakuuttunut onko tieto varmasti persistenttinä sisässä.
Kysymykseen tulevat sitten sellaiset asiat kuin Myslin writecache, veikkaisin että se on mahdollista pakottaa eli siis mysli huolehtii että tieto puristetaan levypinnalle ennenkuin palautetaan onnistunut operaatio. Tällöin tiedon persistenssi voidaan sovelluksessa todentaa siitä että paluuarvo tulee. Hidastaa kantaa (koska writecachea ei voi käyttää) mutta silloin tietokanta ei koskaan anna ei-ajantasalla olevaa tietoa persistenssistä takuuvarmasti. Jos kanta kaatuu keskenään niin paluuarvoa ei luonnollisesti tule ja ohjelmiston on huomattava se taas itsekseen ja osattava tarjota erroria.
Toisin sanoen, pakottamalla levykirjoitus taataan että onnistunut operaatio pysyy persistenttinä vaikka kanta kaatuisi millisekuntia myöhemmin.
Siitä eteenpäin ongelma on tietovarannon rakenteesta (raidauksista yms), ei myslistä.
Huvikseni etsin asiasta...
------------------------------
Disable flush transaction on commit
When using InnoDB, by default MySQL flushes data to disk when transactions are commited. This means that each transaction is flushed to disk when it occurs. This provides data security in case the database server crashes.
The default behaviour can be overridden with the following setting:
innodb_flush_log_at_trx_commit = 0
This setting makes MySQL flush the transaction cache every second instead of after each commit. This means transactions are not flushed to disk the moment they happen. While this improves performance, you must decide whether the risk of losing data due to a server crash is acceptable.
-----------------------
MyISAM:eissa transaktiot ovat siis dataturvallisia, mutta suorituskykyä parantaakseen ne saa erikseen konfattua pois päältä.
Vastasiko kysymykseen?"MyISAM:eissa transaktiot ovat siis dataturvallisia, mutta suorituskykyä parantaakseen ne saa erikseen konfattua pois päältä."
MyISAM ei tuo transaktioita ollenkaan. Vain InnoDB tukee ja se ei ole MySQL tiimin tekemä. MySQL on aika sillisalaatti, eri tietokanta moottorit tukevat erijuttuja.
- lapm
Itse en näe mitään noista rekistereistä sellaisena ettei sitä voisi laittaa MySQL kannalle. Esim. replikoinnilla saadaan tietokantaan vikasietoisuutta kun sama kanta on käytännössä useammalla koneella.
Kunnolla koodattu sovellus myös varaa tarvitsemansa taulut tarvittavilla oikeuksilla käsittelemisen ajaksi, jolloin muut mahdolliset käyttäjät eivät pääse sotkemaan asiaa.
Käyttäänhän MySQL kantaa varsin isoissakin yrityksissä. - teistä ei taída
tietää mitä ACID tarkoittaa?
- kriteerii
joka takaa että tietokanta on pystyssä. toimivana, vailla virjeitä ydinpommin jälkeenkin.
Salasana??
Savolaiset asialla? - asiantuntia 10:33
Sehän oli jotain pomppumusiikkia?
- rmac
Jos puhutaan oikeasti kriittisestä järjestelmästä mitä merkitystä sillä on paljonko tietokantalisenssi maksaa? Jos ei puhuta mainframeista neljällä CPUlla pyörivä DB2 lähtee jo parilla tonnilla.
Vaikka tämä ei suoraan kysymykseen liitykään minusta on aika arveluttavaa nostaa joku ratkaisu ylitse muiden vain siksi, että sen lisenssi on ilmainen. mySQL:n "ongelma" on siinä että kun se on niin helposti saatavissa se on luonut koko joukon tietokanta-asiantuntijoita, joille tietokanta on musta laatikko joka syö SQLää. Tämä taas johtaa esimerkiksi siihen että kun kyselyt on hitaita koodari yrittää tuskissaan optimoida kyselyitänsä vaikka oikeasti vika onkin moottorin muistiparametreissa, joiden olemassaolostakaan kukaan talossa ei tunnu tietävän mitään.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Ensi kesänä
Näin kesän viimeisenä minuutteina ajattelen sinua. Olisiko seuraava kesä "meidän" kesä? Tänä vuonna ei onnistuttu, mutta703550Anne Kukkohovin karmeat velat ovat Suomessa.
Lähtikö se siksi pois Suomesta ? Et on noin kar? mean suuret velat naisella olemassa1483513Tukalaa kuumuutta
Tietäisitpä vaan kuinka kuumana olen käynyt viime päivät. Eikä johdu helteestä, vaan sinusta. Mitäköhän taikoja olet teh463322- 532769
- 322036
Okei, myönnetään,
Oisit sä saanut ottaa ne housutkin pois, mutta ehkä joskus jossain toisaalla. 😘301962Et siis vieläkään
Et ilmeisesti ole vieläkään päässyt loppuun asti mun kirjoituksissa täällä. Kerro ihmeessä sit, kun valmista 😁 tuskin k401695- 481676
Mihin hävisi
Mihin hävisi asiallinen keskustelu tositapahtumista, vai pitikö jonkin Hannulle kateellisen näyttää typeryytensä961635- 391390