[MEGOLDVA] mysql mentési alternatívák

Adatbázis: SQL, XML DB

mysqldump-al mentek, adatbázisonként. Ez kezd kényelmetlen lenni abból a szempontból, hogy ha már van pl. egy 10G tábla egy adatbázisban, akkor az meghalasztja a mysql-t. Az adott weblap egy idő után nem válaszol miközben fut a dump. Load nem nagy, nem saját magára ment, mégis behal az oldal egy idő után. Mivel lehetne még mysql-t menteni normálisan?

mysql-5.1.70

megoldás: lvm snapshot készítése, majd arról backup második mysql instance indításával.

  • 13748 megtekintés

( handler | 2013. 09. 19., cs – 12:50 )

mentes kozben `iostat -tx 1` outputot nezd meg, a device util valoszinuleg 90% felett van olyankor, igy mar nem jut io a weblapra

egyebkent xtrabackup, lvm snapshot

A snapshotnak pont az a lényege, hogy egy konzisztens állapotról lesz pillanatképed (előtte mondjuk nem árt egy flush az SQl-re), és a snapshotot kedvedre olvasgathatod, az SQL írhatja tovább a fájlokat, nem fogod látni a snapshotban.

Itt van róla egy hosszabb beszélgetés: http://hup.hu/node/125549&comments_per_page=9999#comment-1624065

> A snapshotnak pont az a lényege, hogy egy konzisztens állapotról lesz pillanatképed

Ezt azért nem vágom. Mitől lenne egy működő diszk kb tetszőleges pillanatában elkészített pillanatfelvétel konzisztens állapotú. Ez kicsit olyan, mintha azt mondanád, hogy akármikor kihúzhatom a diszk tákábelét és konzisztens marad az FS rajta. És OK, hogy csinálok SQL-flush-t, de attól még van alatta egy OS-szintű FS-réteg, meg egy OS-szintű diszk-driver réteg amelyik éppen nem írta ki a diszkre az adatokat. Szóval részletesebben fejtsd ki mire gondolsz.

mert neha nemart az olvasas...

FLUSH TABLES WITH READ LOCK, aztan mehet az lvm snapshot.

regen persona backupja meg fajlszinten (lvm nelkul) backupolt, tehat eleg volt visszamasolni a fajlokat sqlnek, es mehetett is a moka (persze a backup sem egy egyszeru dump parancsbol allt)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

egy acid adatbazisrendszer commitalt tranzakcioi (allapota) barmely pillanatban rekonstrualhatok a stabil tarolorol (disk)

Az elmelegileg stabil tarolot viszont a gyakorlatban is erdemes megvizsgalni, mert nehany layer hajlamos hazudni rola (virtualizacional kulonosen):

http://brad.livejournal.com/2116715.html

( csardij v | 2013. 09. 19., cs – 16:42 )

használj innodb-t, aztán tranzakcióval mentsd le.

Az innodb nekem mindenhol nagyon sokkal lassabb, mint a myisam. Finomhangolások (ezer tutorial alapján) sokat segítettek, de még mindig közelében nincs, pl. tömeges insertnél. tx_log 2, mindenféle buffer meg log méretek, ilyesmiket állítottam. Az egészből nekem az jött le, hogy ahol lehet nem használok innodbt. Ha neked más a véleményed, mi a titkod?

InnoDb-nél még az sem mindegy, milyen fájlrendszer van alatta, mert egy-két bazi nagy fájl van, amiben az adatok vannak (ha csak nem teszed külön fájlokba a táblákat InnoDb alatt, de akkor lesz csak lassú igazán :)
InnoDb-re tervezni kell. Ahol sok tábla és sok kapcsolat van (>100), nagy mennyiségű adatnál az Inno gyorsabb, mint a MyISAM, utóbbinak ugyanis sokkal több FD kell az OS alatt, és megeszi az erőforrásokat.
--
PtY - www.onlinedemo.hu

En nem merek XFS-t rakni a MySQL ala. A mai napig nem viseli el megfeleloen a varatlan ujraindulasokat, es ha valamiert meghal a gep (akarmiert) nem akarok meg pluszba azon is rezegni, hogy vajon egyaltalan lesznek-e meg fajlok rajta.

Nekem az a tapasztalatom, hogy az XFS bar tenyleg dob valamennyit a gyorsasagon, nem annyit, hogy cserebe megerje vallalni a rizikot. Mert hiaba van napi dump a rendszerrol - az csak napi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Tiszta sor, én csak az eredeti írásra reagáltam, miszerint

En nem merek XFS-t rakni a MySQL ala. A mai napig nem viseli el megfeleloen a varatlan ujraindulasokat, es ha valamiert meghal a gep (akarmiert) nem akarok meg pluszba azon is rezegni, hogy vajon egyaltalan lesznek-e meg fajlok rajta.

Ez a viselkedés nem XFS függő. És ugye azt is tudjuk, hogy bármilyen naplózó fájlrendszer esetén a journal sérülése végzetes lehet. Ha pl. lemezhiba áll a háttérben, és sérült a journal, akkor sok adatnak meszeltek, irreleváns, hogy éppen milyen fájlrendszer volt rajta.
Amúgy meg ugyanezt írják sokan a Reiserfs-ről is. Ezek a hype-ok meg onnan erednek, hogy az enterprise gyártók (RH, Novell) ilyenekkel indokolják azt, hogy miért EXTx a default és ajánlott FS.
--
PtY - www.onlinedemo.hu

Attól függ, mekkora része sérül a journal-nak, és mennyi a ki nem írt adat. Ha ő az összesről beszél, azt azért nem értem, mert olyanról, hogy minden adat elveszett az XFS-ről, mert rebootolt a gép véletlenül, még nem igazán hallottam.
Az első kérdésed nem értem. Mit milyenekkel?
Szerk: Értem!
Konkrétan arra hivatkoznak, hogy a legstabilabb és legmegbízhatóbb FS (URL-t nem tudok). Holott láttam már meghalni EXTx-t is.
--
PtY - www.onlinedemo.hu

> Konkrétan arra hivatkoznak, hogy a legstabilabb és legmegbízhatóbb FS (URL-t nem tudok). Holott láttam már meghalni EXTx-t is.

Az RH tudtommal epp valtani keszul xfs-re, vagy legalabbis gondolkoznak rajta.

> Ha ő az összesről beszél, azt azért nem értem, mert olyanról, hogy minden adat elveszett az XFS-ről, mert rebootolt a gép véletlenül, még nem igazán hallottam.

Azert o hallhatott. Mindenesetre konkretan errol beszel:)

En mar lattam ilyen, de az mar jo reg volt.

tompos

Ha az RH váltani akar, azt díjazom - nem hallottam amúgy...
Nekem anno Reiseren 2 disk esett ki egy 3 elemes R5 tömbből, force-szal összerakva a journal rendbe hozta magát. Mivel nyugalmi állapotban halt meg, csak logok végei hullottak el. Backup nem volt, és szerencsére nem lett volna rá szükség. Pedig a Reisert nem tartom annyira stabilnak, mint az xfs-t, de ez is csak szubjektív dolog.
--
PtY - www.onlinedemo.hu

Az a problema, hogy de, XFS fuggo. Van egy darab olyan virtualis gepem, amin olyan cucc van, ami rendszeresen elcrashelteti a rendszert, es nem tudok vele semmit kezdeni, marmnt sem lecserelni, sem frssiteni nem tudom. Amig XFS volt a gyokere alatt, ketszer veszett el mindene, nyomtalanul. Nem tudom, hogy a journal serult vagy valami mas, annyira mar nem emlekszem a hibauzenetre, de mindenfele XFS varazslat bevetese utan is halott maradt a fajlrendszer, mentesbol kellett visszatolteni a tartalmat. Amiota atraktam Ext3 -ra, pont ugyanolyan gyakran crashel el a rendszer, viszont meg egyszer sem tunt el rola egy fajl sem. Valahogy megoldja okosban.

Es mielott egyedi esetre hivatkoznal: ez csak egy pelda volt a sok gep kozul, amit lattam. Jo az XFS, de elsosorban olyan helyre szoktam optimalizalni, ahol be lehet vallalni a rizikojat a nagymerteku adatvesztesnek, mert vagy van olyan mentes, amibol ~azonnal vissza lehet allitani a mukodest, vagy pedig olyan adatokkal dolgozik, amiert nem kar. Az egyik leggyorsabb fajlrendszer, pl. webszerver ala (foleg ha ritkan van iras) szinte biztos, hogy ezt raknam, nagyon jo tapasztalataim vannak vele ilyen teren. Altalanos /var illetve /tmp fajlrendszernek szinten tokeletes (ha valamiert perzisztens /tmp kell). Adatbazisszervernek en nem hasznalom, ha nem kifejezetten muszaj.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Valoszinu egy szalon teszteltel es rosszul. Multithreaded workloadnal, ami egyebkent tipikus, sokkal jobb az innodb, vagy a redo logok merete volt rossz. Ha megmutatod a benchmarkot meg a my.cnf-et, megmondom hol csuszhatott el. Egy szalu bulk insertre jobb lesz a myisam, ha azzal mertel.

nem mértem, nem a benchmark érdekelt, csak lassabb volt a bulk insert igen. Tehát egy wordpress adatbázis innodb, 144 mega az sql dump tömörítés nélkül. A dump megvan pár másodperc alatt, az insert pedig fél óráig tartott, optimalizálás(??) után lement 15 perc alá :D

a my.cnf:
http://pastebin.com/Xw6K5F74

A filerendszer btrfs nodatacow kapcsolóval (mindez xen domu ban)

( Fisher v | 2013. 09. 19., cs – 21:57 )

Kérdés: van-e értelme a snapshotra mentett db dumpolásának? Csak lassabb lesz lementeni és pláne lassabb lesz visszatölteni. Ha később mondjuk csak egy DB-t vagy táblát kell visszarakni, akkor ráér az ember majd akkor ráindítani egy második mysql-t, dumpot csinálni és visszatuszkolni a helyére a.

Akkor felreertettel v. en teged.

> Kérdés: van-e értelme a snapshotra mentett db dumpolásának?

Erre irtam, hogy a biztonsag kedveert menti a snapshotot is _es_ a dumpot is.
Nekem a mellette azt jelentette, hogy parhuzamosan mindkettot. Igy ha beszarik az egyik, meg van lehetosege a masikra. Vmint lattam mar olyan hibat, ami a dump soran elojott, de mashogy vhogy megsem (es viszont).

tompos

Nem. Ha megvan az adathalmazod mas (szoveges) formatumban is, az mar igen (es le is van tesztelve a visszatoltes:D).
Es termeszetesen el vannak rakva a binlogok is, tomoritve, archivalva, mindegyik. A mysql binaris verziok szinten...

Megis, mit fogsz csinalni, ha vmilyen oknal fogva megserul az egyik adatfile (4kB, 1MB, 1GB teruleten)? Jo esetben eszreveszed ezekkel az eszkozokkel. Rossz esetben crashel a mysql. Megrosszabb esetben nem veszed eszre, mert bugos a check table vagy checksum tool, csak 6 honap vagy esetleg 2 ev mulva. Mi lesz az adathalmazoddal? Mert magatol nem fog megjavulni.

Namost mentésről van szó vagy archiválásról? A kettő két külön célt szolgál, és másképp is kell megvalósítani. Én mentésről beszélek.

Illetve ha az feltételezzük hogy bugos a check table vagy az innochecksum, akkor feltételezhetjük, hogy a mysqldump is hibás, ebben az esetben muszáj az adatok helyességét is ellenőrizni. Ha a mysql eldől akkor az egyértelmű jele annak hogy rossz a snapshot, ebben az esetben attól függően hogy hány sikertelen mentést visel el a rendszer vagy ráindítom újra, vagy megvárom, hogy a következő mentés jó lesz-e. Persze ha amúgy a snapshot létrehozása, miegyéb sikeres volt, stb. stb.

Archiváláskor én a teljes környezetet mentem. Ebben benne van a DB, binlog, dumpok, binárisok, OS. Megtehetem, mert apró a DB. Ha nagy DB-ről lenne szó, akkor replikám lenne. Esetleg nem is egy, attól függ.

Node visszatérve az eredeti kérdéshez, felteszem másképp: van-e valakinek rossz tapasztalata a snapshotról visszaállításról? Akár olyan, hogy a snapshotról nem sikerült dumpot csinálni?

( hrgy84 | 2013. 09. 21., szo – 09:22 )

Ha nagyon ragaszkodsz a mysqldump-hoz, es jelenleg nincs lehetoseged masra valtani, akkor --skip-lock-tables. Nem fog lockolni, viszont ez azzal jar, hogy nem biztos, hogy a legfrissebb adatok lesznek a dumpban (nem lesz masodpercre kesz). Ez napi szintu dumpnal annyira nem erdekes, foleg, ha a mentesi idoablak ugy van kiszamolva, hogy amugy relative inaktiv idore esik, mert a kovetkezo napi dump a hianyzo dolgokat ugyis viszi, ha meg nem viszi, nem annak a par percnek az adata fog hianyozni, hanem a komplett nape.

A --skip-lock-tables ugyanakkor nem csodaszer, azzal is lockol, csak o read lockot csinal, nem pedig read-write lockot.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( banyek | 2013. 10. 10., cs – 12:42 )

Na jo, most komolyan.
Eleve ne hasznalj soha (SOHA) MyISAM tablat, mert igaz, hogy gyors tud lenni olvasasnal, de a table lock ki fogja nyirni a performanciat amint irni kell bele.
Elso lepes: legyen minden tablad InnoDB (XtraDB) es akkor ha mysqldumppal akarsz menteni, akkor adhatsz neki --single-transaction kapcsolot, amitol a backupod konzisztens lesz. LVM Snapshotot nem backupolj, mert barmit is csinalsz, egy InnoDB recoveryvel kell kezdened a visszatoltest, amitol en mondjuk kicsit faznek eleve.
Ha egy mod van ra, akkor ne hasznalj mysqldumpot mentesre, azt hasznald csak dump keszitesere, ha menteni akarsz, akkor hasznalj xtrabackupot vagy meg inkabb innobackupex-et, (az utobbi egy wrapper az xtrabackup fole) ezek megcsinaljak azt, hogy az adatbazis snapshotjabol mentenek majd utana raaplikaljak a redo logokat. Konzisztens lesz a backup.
Orulunk.

"Eleve ne hasznalj soha (SOHA) MyISAM tablat"

Elhamarkodott kijelentes. Akkor lehet MyISAM tablat hasznalni, ha alapvetoen nincs sok iras, viszont sok olvasas van. Peldaul egy blogon, ahova naponta kikerul mondjuk 6-8 cikk, es mondjuk percenkent kikerul egy komment, siman jo lehet a MyISAM, mert messze olcsobb eroforrasban, mint az InnoDB.

Egyebkent meg egy csomoszor nem izles kerdese, hogy mit hasznal az ember. A backup tipikusan rendszergazdai feladatkor, es nagyon sokszor mar adott alkalmazast kell lementeni. En kicsit ellenszenvvel viseltetek az olyan hozzaallas teren, hogy ne hasznalj soha ezt vagy azt. Ha a rendszergazdakon mulna, az adatbazisszerver-fejlesztok tobbsege ehenhalna. Es ne feledjuk el, hogy az ilyen implementacios donteseket elsosorban a fejlesztok hozzak, nem pedig a rendszergazdak - mi csak igazodhatunk hozzajuk, esetleg ajanlhatunk dolgokat. Rossznak tartom azt a munkahelyet, ahol a rendszergazdak mondjak meg a fejlesztoknek, hogy mit tehetnek meg mit nem.

Szerintem nem szabad ugy hozzaallni, hogy aki MyISAM-ot hasznal az dogoljon meg. Kicsit olyan ez, mint egy politikus a csaladban: olyan amilyen, de megiscsak csaladtag.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

> Rossznak tartom azt a munkahelyet, ahol a rendszergazdak mondjak meg a fejlesztoknek, hogy mit tehetnek meg mit nem.

Hat pedig ha a fejlesztokon mulna, akkor a legtobb alalmazas tragyahalom modon intezne a dolgait. Eleve egy rendszergazda jo esetben nem sajat kisujjabol kiszopott modon, hanem a ceges policy aklapjan csinal valamit. Szoval noha el tudom kepzelni, hogy MyISAM vs barmi egyeb viszonylataban akar igazad is lehet, hogy a fejleszto jobban tudja, hogy oda az valo, de altalanossagban fenti kijelentesed erosen hibas. (Gondolom akkor a secteam se mondja meg azt, hogy te csak ne pingelgess vaktaba. Pedig sok helyen ilyen-olyan okokbol az se engedelyezett, es ha neked nem az ICMP echo-req es echo-rep atjutasa erdekes, akkor bizony jogos lehet az elvaras, hogy ne pingelt - eleve nem a te dolgod pl. fejlesztokent.)

Nem azt mondtam, hogy a fejleszto jobban tudja, azt mondtam, hogy o hozza meg a dontest, es ez nagyon fontos kulonbseg. Lehetek en barmilyen rossz velemennyel a MyISAM-rol, ha o ugy dont, hogy marpedig az app akkor is MyISAM-ot fog hasznalni, akkor en nem donthetek ugy, hogy akkor meg nem lesz rola backup.

A ping pedig egy teljesen masik problemakor, nem is mennek bele, mert orakig tudok beszelni rola.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ne haragudj, de ez nem helyes igy. Dolgoztam en is sok olyan helyeken, ahol a fejlesztok hoztak meg a rendszerszintu donteseket, es minden egyes alkalommal egy uzemeltetesi pokol lett a vege. Nem azt mondom, hogy opskent le kell korlatozni a feljesztest, hiszen mi vagyok a devert es nem forditva, de szakemberkent kell, hogy szamitson annyit a szavad, hogy ne menjen a fejlesztes fejjel a falnak, mert TE fogsz felkelni hajnali haromkor, es mert NEKED fogjak szetrugni a segged, ha elveszited a live adatbazis egytizedet.

Nyilvan, egy normalis helyen figyelembe veszik a rendszergazda velemenyet. Ezzel semmi problema nincs. De nem az ove a vegso szo, hanem a fejlesztoe, aki egy adott kornyezetre kesziti el az alkalmazast, figyelembe veve vagy figyelmen kivul hagyva a rendszergazda (es masok) javaslatait. Nem mondhatod azt a kesz alkalmazasra, hogy marpedig en ezt az alkalmazast nem fogom menteni, mert nem hallgattatok ram. Ilyen egyszeruen nincs, nem letezik. Ha en ilyet mondanek, nem kellene bemennem a kiskonyvemert, mert utanamhajitanak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ez igaz, de mondhatod egy ilyen alkalmazasra, hogy ez nincs meg kesz, mert nem lehet menteni. Es ha nem lehet menteni, akkor nem tudsz felelosseget vallalni azert, hogy nem veszik el az adatod. Ha meg tudod kapni irasban a fejlesztestol, hogy ok ezt tudomasul vettek, akkor nincs mar semmi problema.

Mondani mindent lehet, csak legfeljebb igazsag nem lesz sok benne. Technikailag ugyanis LEHET menteni a MyISAM alapu rendszereket, csak nem eleg hatekonyan. Kulonbseg van akozott, hogy valamit meg lehet tenni es akozott, hogy valamit hajlandoak vagyunk-e megtenni. Nem ugyanaz a ketto.

Es tudod akkor mar nagy a baj, ha olyan szakmai velemenyt adsz ki, ami viszonylag konnyen megcafolhato.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Sajnalom, de nem igazan tudok egyeterteni veled. Ha egy olyan rendszert uzemeltetsz, amibe naponta belekerul 6-8 cikk, es percenkent egy komment, akkor az InnoDB hiaba igenyel tobb eroforrast, mint egy MyISAM tabla, egeszen egyszeruen meg mindig olyan keves eroforrasra van rendszerszinten szukseg, hogy az igy igenyet tobblet is keves lesz.
Viszont a MyISAM-mal elveszited a tranzakciokat, nem tudod az adatbazisod konzisztensen menteni, ami szerintem mar igazi problema. (Hacsak nem allitod le az adatbazist a mentes idejere, ami megint csak nem egy tul jo otlet.)
Persze, a MyISAM gyors olvasasa hasznos tud lenni, el tudok kepzelni olyan scenariot, ahol csak olvasasra hasznalt adatbazisban ezt hasznalod, es naponta ujrageneralod / dumpolod egy 'mester' adatbazisrol, de ebben az esetben a mentest az eredeti helyen intezheted, a node-okon pedig nem kell torodj vele.
Olyat is el tudok kepzelni, amikor ugyancsak egy readonly adatbazisra (mondjuk egy cdromon) van szukseg, es azt hasznalja az alkalmazas. Vagy amikor file szinten el akarod masolni az adatbazist valahova.
Szoval nem azt mondom, hogy a MyISAM nem egy hasznalhato eszkoz, mert persze az, de nekem dbakent az elso es legfontosabb feltetel az, hogy az adatok biztonsagban legyenek, minden egyeb szempont masodlagos. Ebben szerintem egyeterthetunk.

Persze tudsz kesziteni konzisztens mentest MyISAM tablakrol is, csak akkor meg kell gyozodj arrol, hogy abban az idoben amikor a mentest keszited nem tortenik iras az adatbazisba.
Azt hiszem egy olyan scenariot el tudok kepzelni, hogy megallitod az alkalmazast, csinalsz egy filerendszer snapshotot LVM-mel, ujrainditod az alkalmazast, es mented a snapshotot, de ez leallasi idovel fog jarni, minden egyes mentes eseten. Ez nem egy rossz megoldas, de bele kell kalkulaj a rendszerbe mondjuk napi downtimeokat. Arrol nem is beszelve, hogy ameddig mented a snapshotot, es a snapshot jelen van a diszkeden, addig romlani fog az irasteljesitmeny az eles oldalon is (persze, ha Linux LVM-rol beszelunk, es nem valami storage beepitett feature-rol)
Mondjuk a minden egyes mentes eseten megoldas lehet meg, hogy bekapcsolod a binaris logolast, es a binlogokat mented, amiket aztan tudsz ugy hasznalni recoveryre, hogy mysqlbinlog utilityvel ragorgeted az utolso konzisztens backupra. Ez se rossz, de sokaig tud tartani, ha mondjuk 1-2 hetente csinalsz konzisztens mentest.
Megteheted meg azt is, hogy felhuzol egy mysql slave-et, es a slavet mented (szigoruan egy stop slave; start slave; kozott) ez meg a legjobb megoldas, de ebben az esetben sok eroforrasra lesz szukseg (legalabbis diszkben mindenfelekeppen)

Szoval persze, hasznalhatsz MyISAM-t, de amit megsporolsz a reven (egyszerubb konfig, kevesebb eroforras) azt elveszited a vamon (problemak a konzisztens mentessel, rossz teljesitmeny irasra.)

Szerintem manapsag mar nem igazan eloremutato fejlesztokre / rendszergazdakra osztani az informatikat, egy fejlesztonek igenis legyen fogalma arrol az eszkozrol, amit hasznalni fog (nem kell, hogy mely ismeret legyen, de legyen arrol elkepzelese, hogy mire lehet kepes, es ezt a rendszergazda tudja elmondani neki) a rendszergazdanak meg legyenek ismeretei programozasbol, eszkozokrol, es akkor meg tudja talalni azt a megoldast, ami a fejlesztonek is jo lesz.
(lasd: ops / dev / devops)

" az InnoDB hiaba igenyel tobb eroforrast, mint egy MyISAM tabla, egeszen egyszeruen meg mindig olyan keves eroforrasra van rendszerszinten szukseg, hogy az igy igenyet tobblet is keves lesz. "

Ha viszont mindez magas olvasottsagi rataval parosul, peldaul egy hirportal eseteben, akkor viszont az InnoDB terhelese mar szamottevoen nagy lesz.

"Viszont a MyISAM-mal elveszited a tranzakciokat, nem tudod az adatbazisod konzisztensen menteni, ami szerintem mar igazi problema. (Hacsak nem allitod le az adatbazist a mentes idejere, ami megint csak nem egy tul jo otlet.)"

A tranzakciok elvesztese nem biztos hogy fajdalmas, foleg, ha maga az app sem hasznal tranzakciokat. Az InnoDB es a tranzakciok ugyanis nem jarnak implicite egyutt.

Egyebkent MyISAM eseteben letezik a WRITE LOCK intezmenye, amitol meg nem hal meg az adatbazis, viszont konzisztens backupot tudsz csinalni, plusz a FLUSH TABLES egyben konzisztens allapotot er el.

Az utolso bekezdesre csak egyet reagalnek: jo lenne, ha ilyen szep vilagban elhetnenk. Sajnos a valosag ennel sokkal mocskosabb.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Ha viszont mindez magas olvasottsagi rataval parosul, peldaul egy hirportal eseteben, akkor viszont az InnoDB terhelese mar szamottevoen nagy lesz."
Igen, de a memoria olcso, es memoriaval szepen fel tudod skalazni a rendszert. Egy hirportal latogatasi statiszikaja foleg arra epul, hogy a friss hireket olvassak sokan, szoval nem kell az egesz db-t beleturnod a buffer poolba.

"A tranzakciok elvesztese nem biztos hogy fajdalmas, foleg, ha maga az app sem hasznal tranzakciokat. Az InnoDB es a tranzakciok ugyanis nem jarnak implicite egyutt."
Valoban. Viszont a mentest te el tudod egy tranzakcio alatt intezni, ami azt fogja eredmenyezni, hogy a tranzakcionak koszonhetoen 0 downtimemal mentheted a dbt. -> konzisztencia.

"Egyebkent MyISAM eseteben letezik a WRITE LOCK intezmenye, amitol meg nem hal meg az adatbazis, viszont konzisztens backupot tudsz csinalni, plusz a FLUSH TABLES egyben konzisztens allapotot er el."
Igen, ez teny, de ha WRITE LOCKba teszel egy adatbazist, akkor nem tudod irni. Igaz ugyan, hogy kiszolgalni ki tudod a friss hireket, de nem lehet mittomen kommentelni, breaking hirt felrakni, kommentelni stb. Ez is egyfajta downtime, meg ha nem is olyan fajdalmas, mint egy "karbantartas alatt" oldal.

"Az utolso bekezdesre csak egyet reagalnek: jo lenne, ha ilyen szep vilagban elhetnenk. Sajnos a valosag ennel sokkal mocskosabb.
"
Igazabol ez csak rajtunk ops/dba embereken mulik. Nem egy konnyu eset, mert eleg sok olyan hely van, ahol minket "masodosztalyu" informatikuskent kezelnek, de ha ezt tenykent kezeljuk, akkor ez igy fog maradni.