Havárie databáze

4. 4. 2007 | Redakce | Novinky | 5379×

Kvůli havárii databáze jsme byli nuceni provést obnovu z poslední zálohy, která proběhla o půlnoci z 3. na 4. dubna. Došlo proto ke ztrátě dat.

Těžko o tom mluvit a těžko hledat omluvy. Kvůli souhře několika nepříjemných náhod a okolností došlo k problémům s databází portálu. Byli jsme nuceni obnovit obsah ze zálohy. Poslední záloha byla provedena o půlnoci z úterý na středu, tedy ze 3. na 4. dubna 2007.

Veškerá data od této půlnoci byla ztracena - tj. komentáře, zprávičky, blogy a všechny další záznamy na portálu. Ačkoliv jsme tomu samozřejmě nejprve nechtěli sami věřit, bohužel se tak stalo. Nic podobného se nám ještě za dobu provozování abclinuxu.cz nestalo a doufáme, že máme problémy vybrány na několik let dopředu.

Byli bychom rádi, kdybyste nám mohli zaváhání odpustit, jakkoliv může být nepříjemné. Jsme si vědomi toho, kolik komentářů a dalších příspěvků každý den na abclinuxu.cz přibude, takže je nám jasné, o jak závažnou ztrátu dat se jedná. Přesto věříme, že to více či méně pochopíte a budete to - stejně jako my - považovat za příhodu, která se stala poprvé a naposledy.

Redakce.

       

Komentáře

[trekker.dk]

Kdybyste místo čtyřky, která má nepříjemné bugy, použili pětku, která je má taky, ale umí se z nich zotavit, nikdy by se to nemohlo stát

[thingie]

Nebo kdyby použili skutečnou databázi

[Honza Balák]

Třeba Firebird

[Kyosuke]

...který se snadno zálohuje za chodu (a to i inkrementálně, takže pak není takový problém zálohovat často) a nasazený v palubním počítači tanku bez problémů vydrží i časté výpadky způsobené kanónovou střelbou? Ne, to by pak bylo příliš jednoduché.

[NbS]

neb jak pravi klasik, "jednoduche veci me nezajimaji" :))

[Luk]

Moje řeč

[Vlastimil Ott]

Kdo nic nedělá, nic nezkazí.

Doufám, že růžový styl je v pořádku.

[hub]

Doufám, že růžový styl je v pořádku.

Doufám, že to nepřežil.

[Lukáš Rýdlo]

Rád bych věděl, jak se ho zbavit. Našel jsem už jen ten tmavý, ale chtěl bych zpět ten světlý . Ale zdálo se mi divné, že mám místo tmavé růžovou a že nemůžu najít některé komentáře . Nu což, to se stává i v lepších rodinách, jak říká moje maminka .

[Robert Krátký]

Mělo by pomoci promazání cache prohlížeče.

[xkucf03]

Stačí shift+F5. Mazat cache není potřeba.

[razor]

To je jako univerzální klávesová zkratka pro všechny prohlížeče ? :)

[Lukáš Rýdlo]

Díky za nabídnutá řešení, nakonec jsem to "spravil" přepnutím na černý styl a po jednom dni zpět na bílý a ona se ta cache přemazala sama .

[AraxoN]

Odpustíme Vám, ale mohli by ste načrtnúť čo sa vlastne stalo a ako ste to riešili - aby sa ďalší ľudia mohli inšpirovať, prípadne vyvarovať rovnakých chýb.

Vopred ďakujeme. Vaši čitatelia.

[diverman]

+1

Docela by me zajimalo, na cem to bezi (MySQL, PostgreSQL, Oracle...)?

[Bubak]

Kdyby to byl Oracle, tak by se tohle nestalo... Prisli by maximalne o par minut anebo vubec o nic - podle zpusobu zalohovani a druhu problemu - ruzne konstelace samozrejme mohou mit ruzne nasledky a i pri ne uplne vyladenem zalohovani muze clovek neprijit o data.

[Lukáš Rýdlo]

OT: Jo, a kdybychom posílali všechny komentáře poštou a vytesané do kamene, tak by se daly dohledat a neponičil by je ani požár . Navrhuji místo koupě Oracle najmout kameníky a objednat pořádné žulové bloky . Nic ve zlým, ale když někde vidím "kdyby", vždycky vymýšlím nějaké "dokonalé scénáře" . (Ještě mě napadá -- co by vyšlo levněji? )

[Bubak]

Ja pouze castecne odpovedel na otazku podle vlastni zkusenosti. Nikomu koupi Oracle nenavrhuji a za dokonale scenare jsem komukoliv vdecny. Ver mi, ze zalohovani me eminentne zajima, protoze u zakazniku si nemohu dovolit ztratit data a zatim se mi to i pres ruzne i hruzne udalosti nepodarilo. A myslim, ze z vetsi casti za to muzu dekovat Oraclu a rozhodne ne sve "chytrosti". "Kdyby" znamenalo vylouceni jedne moznosti dane ve vyctu v predchozim komentari, nic jineho.

OT: Nevim, nevim, jestli by te kamenici prisli levneji. Pri dnesnim kapitalismu...

[Max]

Oracle je bezesporu špička na trhu. O jeho bezkonkurenčním výkonu snad nemůže nikdo pochybovat. Navíc má opravdu skvělou dokumentaci a propracované zálohování. Když se k tomu přidá jeho multiplatformita a stabilita, tak člověk zjistí, že ten melounek nejni zas tolik :). Ale tohle je extrém pro mega firmy, třeba s posgresql nemám vůbec žádnou zkušenost, vlastně se pohybuji v kruhu MySQL, Oracle, MS SQL :-/
Zdar Max

[trekker.dk]

Ale tohle je extrém pro mega firmy...

... a státní správu.

[Bubak]

Pro firmy ten melounek opravdu takovy problem neni. I kdyz u nas... Nebudu to komentovat.

Ja ted o zadnem kruhu mluvit nemuzu, proste jsem nucen pouzivat Oracle. Ne, ze by mi to moc vadilo, vetsinou nedela zadne problemy. Ale jak jsem psal nize (take na tvuj komentar), chystam se v nejblizsi dobe opet otestovat Postgresql a pripadne ho pouzit i (alespon) pro nektere vnitrofiremni aplikace. Pak by se videlo, co vsechno by slo dal...

[Max]

No, nejsem žádný odborník :). Na MySQL jsem si pořídil před pár měsíci knížku, je to jednoduchá databáze a dost mě zajímá. Oracle máme v práci a ten mě taky dostal a ještě víc mě dostalo jeho vývojový prostředí APEX (dříve HTMLDB) a v neposlední řade produkt PL/SQL Developer. MS SQL máme taky v práci (kvůli dosti věcí, které nutně vyžadují MS a nic jiného) a jako ee, moc se mi nelíbí :(
Zdar Max

[Marián Kyral]

Ani ten Oracle není bez chyby. Nedávno se u jednoho našeho zákazníka objevil problém s integritou datových souborů a zastavilo to celý sklad. Zálohy týden zpátky byly taky poškozené a nebylo vůbec jednoduché to zase znova rozjet. A když se zastaví sklad uprostřed noci, když tam je největší provoz, tak je to dost velký problém. Obchody pak nemají ráno co prodávat.

[Max]

Otázkou je, čím to opravdu bylo způsobeno :-/. Vždy je možný všechno ...
Zdar Max

[peter_h]

No akurat vcera som videl nejake testy vykonu na SAP, oracle z toho nevysiel prave najlepsie, najlepsie z toho vyslo ms sql, lenze tam netestovali skalovatelnost, nema kazdy pristup k systemu s 64 CPU. A za tym vychadzalo celkom dobre maxDB. Ja som skor pocul o Oracli len to, ze ma najlepsiu integritu dat, ale o vykone ani moc nie.
Problem je, ze firmy zakazuju robit testy svojich DB. Ale poznate to - su klamstva, tazke klamstva a benchmarky.

[jaromir]

teda existuje neco jako Oracle express.. a vzhledem k tomu, ze kazdej den mam na starosti zalohovani cca 600 databazi Oraclu (.. ne jak mi jeden konkurentni kolegu rikal, ze ma fakt velkou databazi.. 17G.. sem se poprskal..) Me spis prekvapuje, ze ta zaloha byla tak stara.. normalne slusne paranoidni admin zalohuje kazdou hodinu :))

[Leoš Literák]

No, uz jsem o tom zacal uvazovat. Jeden cas mi mysqldump blokoval celou aplikaci, nez jsem nasel spravny prepinac. Ted uz by to asi nevadilo.

[Marián Kyral]

Me spis prekvapuje, ze ta zaloha byla tak stara..

Já jsem psal: "Zálohy týden zpátky byly taky poškozené"

Ono těch zálohy bylo samozřejmě více, poslední byla stará maximálně 4 hodiny, ale všechny byly poškozené.

[Lukáš Rýdlo]

Já to chápu , ale myslím, že Oracle je pro ábíčko trochu zbytečný nadstandard . Btw. teď mi nedávno nezávisle na sobě tvrdili dva lidé, co dělali dřív s Oraclem, že teď používají DB2 a jak jsou z ní nadšení, že je lepší... Ale sám mám zkušenosti jen s MySQL a nepříliš hluboké, takže nehodlám soudit. Jediné co vím jistě (a říkali to i na přednášce), že z hlediska dlouhodobeho zálohování dat je nejlepší medium kámen. Akorát má prý nepříliš dobrou kapacitu a taky se na něj špatně zapisuje .

[Filip Jirsák]

Jediné co vím jistě (a říkali to i na přednášce), že z hlediska dlouhodobeho zálohování dat je nejlepší medium kámen. Akorát má prý nepříliš dobrou kapacitu a taky se na něj špatně zapisuje .

Přenosová rychlost (kb/s – kamenné bloky za sekundu) taky není nejlepší

[Max]

Kdo má skoro milion Kč na oracle, ať zvedne ruku ...
Zdar Max

[Bubak]

Najdou se, neboj...

Ale mam dojem, ze Postgresql se uz take blizi k rozumnemu zpusobu zalohovani. Chystam se ho v nejblizsi dobe opet zkontrolovat. Byla to ma oblibena databaze na soukrome veci.

[Max]

JJ, najdou, třeba naše firma běží kompletně na oraclu :), zálohy xkrát denně atd.
Další parádní věc je, že vydali verzi pro volné používání (i komerční), sic je celkem omezena, ale pro obyčejného smrtelníka je to super věcička a o apexu nemluvě :)
Zdar Max

[Bubak]

Jo, nevim, jak je to s tim milionem, to je vec obchodniku. Zalezi na tom, co dotycny potrebuje, ceny muzou byt hodne ruzne...

[Max]

Mno, oni ho prodávají buď na počty procesorů, nebo na počty uživatelů. A liecnce na počty procesorů (neomezeně uživatelů) je oproti té s počtem uživatelů, x krát dražší a to ti žádnej obchodník neusmlouvá :-/.
Zdar Max

[Bubak]

Ja vim, jak to funguje, myslel jsem to tak, ze od toho jsou obchodnici, aby to prodali. Na to ja nemam zaludek a nervy.

[Leoš Literák]

Myisamchk byl spusten, ac bezela aplikace. Od te doby doslo k poskozeni a nekonzistenci dat, nesmyslnemu chovani, duplikatnim klicum atd. Proto jsme urychlene vypnuli aplikaci a spustili myisamchk -r opet. Z mne nepochopitelneho duvodu se ztratila vsechna data od 3.4. 9:32. Proto jsme museli nasadit posledni zalohu (a jeji zprovozneni dalo taky zabrat, nekolikrat jsme dostali chybu: "Incorrect key file for table 'relace'; try to repair it".

[AraxoN]

Uff, to je story ako z hororu. Bol nejaký zvláštny dôvod na to spustenie myisamchk za behu mysqld? Alebo to púšťate len tak - preventívne? Nestačil CHECK TABLE, ANALYZE TABLE, a spol.?

[Leoš Literák]

Dal jsem pozadavek na optimalizaci databaze. Nevypnuti mysqld byl dusledek spatne (prectene|napsane) dokumentace.

[AraxoN]

Stane sa každému.

[Filip Jirsák]

Aspoň už teď známe ty argumenty protivníků ve flamewarech, a můžeme to sjet ještě jednou, a tentokrát už stručně, rychle a s vybroušenými argumenty

[Lukáš Rýdlo]

Jenže já už zapomněl své brilantní argumenty. Spoléhám na to, že stabilita databází je vyšší než stabilita mé paměti (počítaje v to i ten výpadek) .

[Marek]

Potykal jsem se s podobnymi problemy nekolikrat, coz me privedlo az ke kroku, ktereho dnes vubec nelituji, ba naopak.. Ano, podobne problemy me prinutily hledat jine reseni nez MySQL..

Netvrdim, ze se jednalo o jednoduchy zakrok, nicmene po mirne zmene architektury aplikace (ktera byla stejne drive nebo pozdeji nutna), jsem presel na kombinaci SQLite + PostgreSQL..

SQLite slouzi v podstate jen jako cache pro nejcasteji tahane a vicemene nemenne data v PostgreSQL.. Jestli nekoho zajima vykonnostni rozdil, mohu potvrdit narust vykonu - ale prikladam to spise lepe promyslene architekture, nez vymene databazoveho enginu..

Co je pro me a koneckoncu i uzivatele nejdulezitejsi, s PostgreSQL doposud nebyl jedinny problem ! (cca rok provozu)

Jen doplnim, ze se jedna o dle meho nazoru celkem vytizenou webovou aplikaci (cca 300tis pozadavku/den)

M.

[Filip Jirsák]

Potykal jsem se s podobnymi problemy nekolikrat

Vy víte, co se stalo, když píšete o „podobných problémech“? Přestože podle toho, co vím, v tom v tomto případě MySQL není úplně nevinně, nemám rád tohle automatické odsuzování MySQL, rádobyvtipné komentáře, že to není databáze apod. Ono je sice hezké se takhle vymezovat vůči těm, co „programují“ v PHP a MySQL a o programování a databázích nevědí skoro nic, ale mám pocit, že spousta těch, co se takhle vymezují, toho ve skutečnosti o databázích neví o moc víc a akorát papouškují o MySQL to, co někde zaslechli. Čímž se nechci nikoho v této diskuzi dotknout, jenom upozorňuju, kam se takovými komentáři zařazujete. A to říkám jako někdo, kdo přechod MySQL → PostgreSQL také podstoupil – ale vím proč jsem si vybral PostgreSQL a přestal používat MySQL. A rozhodně si nemyslím, že by MySQL byla tak špatná databáze, že není potřeba dokládat argumenty důvod přejít na jinou databázi. A dokonce si myslím, že ve spoustě případů je použití MySQL opodstatněné.

[Marek]

Ano, vim, ze doslo ke ztrate dat a to mi staci - mel jsem stejne problemy.. V mem prispevku nepadl jediny, jak pisete, radoby vtipny komentar, ani jedine slovo proti MySQL - jen jsem uvedl, jak jsem tento problem vyresil. Jen pro vasi informaci, ac nemam nejmensi chut s vami diskutovat a polemizovat na tema databazi, nebot je to vecne tema, ktere ma v kazde situaci sve argumenty pro a proti pro jiny produkt, take vim, proc jsem se rozhodl pro PostgreSQL a uprimne by na tento prechod doslo pravdepodobne i v pripade, ze by s MySQL nebyly zminene problemy..

[Filip Jirsák]

Ano, vim, ze doslo ke ztrate dat a to mi staci - mel jsem stejne problemy..

Ke ztrátě dat dojde zpravidla použitím DELETE, DROP, nebo rm, a nesváděl bych to ani na databázi ani na souborový systém…

V mem prispevku nepadl jediny, jak pisete, radoby vtipny komentar,

To máte pravdu, ty komentáře byly o něco výš od někoho jiného a ani mi nestály za samostatný komentář…

ani jedine slovo proti MySQL

řekl bych, že vyznění toho komentáře je proti MySQL

[Marek]

Stejne jako v pripade teto ztraty dat portalu (coz jen predpokladam), ani v mem pripade se data neztratily pouzitim vami vyjmenovanych ani podobnych prikazu. Doslo k poskozeni internich struktur tabulek - s neznamych duvodu

Abych vas uklidnil, neb to evidentne potrebujete, MySQL nadale pouzivam v jinych aplikacich, ktere nejsou takto narocne na dostupnost/spolehlivost..

M.

[Filip Jirsák]

Stejne jako v pripade teto ztraty dat portalu (coz jen predpokladam), ani v mem pripade se data neztratily pouzitim vami vyjmenovanych ani podobnych prikazu. Doslo k poskozeni internich struktur tabulek - s neznamych duvodu

Že se to nestalo použitím zmíněných příkazů jste ale v době psaní prvního příspěvku nejspíš nevěděl. A v tomto konkrétním případě jsou důvody poškození známé, spustit pg_resetxlog nad běžícím PostgreSQL by asi mělo podobné důsledky. Jiná databáze by možná déle odolávala "útokům" svého správce – což by se zase mnohým nelíbilo, protože přece správce ví, co dělá, když spouští nějaký příkaz. Co mne spíš zaráží a beru to jako výrazné mínus pro MySQL je schopnost vyrobit zálohu s duplicitami v unikátních klíčích, která pak zákonitě nejde obnovit bez problémů.

[freshmouse]

Ono je sice hezké se takhle vymezovat vůči těm, co „programují“ v PHP a MySQL a o programování a databázích nevědí skoro nic, ale mám pocit, že spousta těch, co se takhle vymezují, toho ve skutečnosti o databázích neví o moc víc a akorát papouškují o MySQL to, co někde zaslechli.

Jeden známý začal být jednoho krásného dne "webovým vývojářem". První den se mě ptal, jak se používá SELECT. Druhý den chtěl poznat propojení tabulek. A třetí den mi řekl, že na MySQL sere, protože to je sračka. Takže tak.

[AraxoN]

Taktiež máme s Postgresom dlhoročné pozitívne skúsenosti.

[trekker.dk]

Výňatek ze zprávy: Nic podobného se nám ještě za dobu provozování abclinuxu.cz (to je teď kolik... deset let?) nestalo...

Tvůj komentář: Co je pro me a koneckoncu i uzivatele nejdulezitejsi, s PostgreSQL doposud nebyl jedinny problem ! (cca rok provozu)

Řeknu ti jenom jedno - nemachruj.

[Marek]

Vyjadreni zkusenosti, v tomto pripade nijak expresivnim zpusobem, podle me neni machrovani..

[trekker.dk]

Je jedno jaký způsob jsi použil k vyjádření zkušenosti... to podstatné, na co poukazuji, je, že ábíčko běží už několik let (v poradně zmizel odkaz na nejstarší dotaz, takže nezjistím, jak dlouho), kdežto ty ses vytasil s (pouhým) jedním rokem bezproblémového provozu.

[Marek]

Ano, uznavam, moje zkusenost s provozem je kratsi - rok na PostgreSQL, predtim pul roku na MySQL.. Nicmene problemy se projevily jiz behem toho pul roku, coz pro me bylo rozhodujici..

[Michal Ludvig]

Samozrejme, po pul roce pouzivani bezesporu dokazete kvalifikovane pohovorit na tema spolehlivost MySQL :D Spis bych to videl tak ze se projevil znamy problem PEBCK ktery vsak neni specificky pro MySQL ale pro uzivatele-zacatecniky obecne

[Kyosuke]

A proto je dobré v co největší míře používat zero-management databáze typu Firefird. 0:-)

[Marek]

Pul roku jsem s MySQL pracoval v tomto projektu Ale nebojte, jsem a budu jejim jiz dlouholetym uzivatelem

[camlost]

Marku, myslim, ze tu ztracite cas. proste jste se dotkl jejich citliveho mista.

je to proste - zatimco Vy o tom nevite nic, "oni" jsou DB gurus.

[Petr (DotaZ) Jakubec]

pozor na ty zkratky!!

nebo si i DB vylozi jinak

a co procesory ktere jsou nejlepsi? jak male deti...

kazdy prece vi, ze nejlepsi DB je ta ktera se nejvic hodi pro ten dany ucela a spravce ji nejlepe umi. tady (u abicka) je MySQL jako dedictvi z dob predchozich a vyber byl pri jinych podminkach, kdovi, kdyby ted volili jakou DB by zvolili...

ps: proti nesikovnemu popletovi nema sanci i ta "nejlepsi" DB...

[Leoš Literák]

Abicko jsem spustil zacatkem unora 2002, takze tak stare zase neni. A pamatuji si par prusvihu Vetsinou byla pricinou mysql ci jeji spatne nastaveni (hlavne teda locale), s ni valcim i dnes, po prechodu na UTF, coz melo tyto problemy navzdy vyresit (viz vikendove problemy s autory).

[trekker.dk]

Z jistého důvodu jsem si myslel, že funguje už kapku dýl.

[Leoš Literák]

Abicko obsahuje i vsechna data z Linux Hardware, ktery jsem psal na ukor diplomky v roce 1999

[trekker.dk]

Abicko obsahuje i vsechna data z Linux Hardware,...

Jj, pamatuju si, že to jsi už někde psal.

...ktery jsem psal na ukor diplomky v roce 1999

Proč jsi Linux Hardware neudělal jako diplomku? V tvém, ehm, životopisu se píše, že jsi vystudoval informatiku, takže na první pohled bych řekl, že by to jako téma projít mohlo...

[thingie]

Linux Hardware mi na diplomku studenta informatiky přijde takový projekt ne úplně odpovídající...

[Michal]

Pocet pozadavku je sice velmi malo vypovidajici hodnota ale kdyz uz srovnaavme nesrovnatelne...

Dlouhodoby prumer 322 qps, ve spickach dvojnasobek. To je nejakych 28M dotazu/den. 25% z nich jsou zapisovaciho charakteru. Databaze MySQL, vetsina tabulkem v MYISAM, casto updatovane tabulky v InnoDB. 2 roky provozu, 0 problemu. Klepy klepy na drevo.

[Marek]

Nepresne jsem se vyjadril - 300tisic pozadavku denne bylo mysleno jako 300tisic requestu na urovni webove aplikace (bez statickeho obsahu).. Do databaze mimo webove aplikace jeste pristupuje cca 50 uzivatelu pomoci administracni GUI aplikace..

M.

[Michal]

PV i online uzivatelu mame radove vice. To je ale jedno, ja se do zadneho "pretahovani" pustit nechtel, nemam to zapotrebi. Ostatne ze MySQL zvladne obrovskou zatez je znama vec. Treba

http://gaiaonline.com/forum/

(Gaia has 988,106,670 articles posted with 6,799,828 registered users. Most users ever online was 86,738 on Thu Jan 04, 2007 3:00 pm)

jede na MySQL. Tady pujdou do databaze desitky tisic dotazu za vterinu.

[R]

300 tisic za den je nic (ak su to query) - my mame 250 tisic za hodinu... Je to MySQL a bezi to na Celerone 1.7GHz, 1280MB RAM. Je to tak do 200 tisic hitov za den na jednom webe (najvacsom, co tam je - bezi tam este niekolko mensich).

[freshmouse]

Jste si vybrali zrovna dobu, kdy jsem napsal několik KB textu o školství. Néé.

[Lu-Tze]

Nemyslím si, že je na světě někdo, kdo by se nejdřív nepodíval, jestli mu ten text zmizel nebo ne, a místo toho psal nějakej komentář. Takže to beru jako reklamu na tvůj další blog

[freshmouse]

Co? Bylo to v komentářích u jednoho z weblogů tady na ABC...

[Lu-Tze]

Už podruhé dnes musím psát: sorry. Nějak jsem si to blbě přečel. Myslel, že píšeš něco jako "jestli jste si zrovna vybrali dobu..." a předpokládal jsem, že máš rozepsanej nějakej zápisek...

[freshmouse]

Všechny příspěvky do weblogu mám na disku jako plain/text.

[freshmouse]

Ještě jsem chtěl ale dodat, že se to může stát kdekoli a komukoli a že se prostě nedá nic dělat.

[Filip Jirsák]

Já bych dokonce řekl, že se to jednou stane každému, a je jen otázky kdy a jak velký to bude průšvih. A klepu tady na dřevěnou desku stolu, že ty moje průšvihy byly zatím menšího rázu a spíše pro ponaučení.

[trekker.dk]

Jak zpívá pan Jahelka:

Co se stalo, stalo se,
odestát se nemůže,
co se stalo, stalo se
a člověk nic nezmůže

Osobně bych řekl, že se nestala zas tak velká katastrofa; kdo pokládal dotaz, ten si snad za ten den vzpomene, co psal, a pokud nebylo vyřešeno, zeptá se znova.

[jozka]

No a duvod vypadku se nasel

[Messa]

Článek je napsaný tak morbidně, jako by poslední záloha byla z léta.

[finn]

Již Jan Amos Komenský pravil, že …když nejde vo život, tak de vo hovno…

[Jiří (BoodOk) Kadeřávek]

Asi jsem neměl obvnit Oracle z parazitování na RedHatu. Ale že můj komentář odstraní takhle brutálním způsobem, to mne nenapadlo

[Jiří (BoodOk) Kadeřávek]

Mimochodem, není pro tyto situace vhodné držet binární log?

[Andrej]

To mi připomíná znamenitou historku, jak kdysi na jedné fakultě měli Raid 6. Moc nezálohovali - proč taky, vždyť přece mají Raid 6, ne? Jednoho dne selhaly tři disky najednou a bylo po legraci.

Je to neuvěřitelné. V případě použití extrémně špatných disků by pravděpodobnost selhání jednoho disku během jednoho dne mohla být třeba E-3, ať se to dobře počítá. Pak je pravděpodobnost selhání tří disků během jednoho dne E-9. (Pokud by neselhaly všechny v jediný den, správce by jednoduše stihl porouchaný disk vyměnit a katastrofa by se nekonala.)

Asi to musel být nějaký náhlý vnější vliv (vibrace, EMP (blesk), kafe nalité do diskového pole). Ať tak nebo tak, stalo se to.

[Tonic]

bylo by zajimave tuhla pravdepodobnot spocitat

[Andrej]

Tak to by zas nebyl takový problém. Doba života disků se řídí (většinou asi) exponenciálním rozdělením. Stačí zjistit, jaká je pravděpodobnost, že jeden disk nepřečká následující den, a tuto pravděpodobnost umocnit na třetí.

U dobrých disků se udává hodnota MTBF, která by se jistě dala převést na parametr λ exponenciálního rozdělení. Teď přesně nevím, jak se to vypočte a nechce se mi sahat po skriptech ze statistiky.

Výpočet, který jsem zvolil, byl střelený od boku. Hádal bych, že skutečná pravděpodobnost selhání bude ještě mnohem nižší.

[MJ]

Tak to by zas nebyl takový problém. Doba života disků se řídí (většinou asi) exponenciálním rozdělením.

To je pravda, ale sotva platí, že selhání jednotlivých disků v poli jsou nezávislé jevy, jejichž pravděpodobnosti by bylo lze násobit.

[Andrej]

Selhání jednoho disku neovlivní ty ostatní, protože nezmění provozní podmínky a nezvýší zátěž. (Větší zátěž nastane až tehdy, když někdo poškozený disk vymění a pole se zotavuje, ale to už je jiná historie.) Ať přemýšlím jakkoliv, nevidím absolutně žádnou závislost mezi selháními dvou disků pole - určitě ne v tom významu, který definuje matematická statistika.

[Filip Jirsák]

Není závislost mezi výpadkem jednoho disku a výpadkem druhého disku, ale je závislost výpadků obou disků na něčem třetím, společném.

[Andrej]

Ano, jistě, o „vnějších vlivech“ jsem už někde níže psal. Jsou koneckonců jediným možným vysvětlením takové události.

[josef]

Třeba na seriových číslech, po sobě jdoucích...

[xsubway]

Asi to musel být nějaký náhlý vnější vliv (vibrace, EMP (blesk), kafe nalité do diskového pole). Ať tak nebo tak, stalo se to.

Jsou i horsi veci

[Jakub Suchy]

A prito mto neni nic tak nepravdepodobneho. Nam uz se to stalo taky. Ale my zalohujeme

[Andrej]

Když už se to stane, musí v tom být nějaký vnější faktor. Třeba opravy v budově a vibrace od zbíječky, které během pěti minut dokáží snížit životnost nových disků třeba na třetinu. Nebo studený start, kdy se z nějakého důvodu rozběhly disky v chladné místnosti. Výpadek klimatizace...

Když se to bere z tohoto pohledu, je selhání až nepříjemně pravděpodobné. V tom máte určitě pravdu. Ale je zhruba jen tak pravděpodobné jako zmíněné nepříznivé jevy. Bez nich by bylo skoro vyloučené. (Za předpokladu, že jsou včas k dispozici náhradní disky.)

[Jiří (BoodOk) Kadeřávek]

Žádný vnější faktor v tom nemusí být (ale může). Máte v poli disky ze stejné výrobní série a třeba se stejnou výrobní vadou (ale stačí aby byly na konci životnosti, dech jim dojde velmi pravděpodobně v krátkém časovém rozmezí všem). Odejde jeden a jak zastavíte stroj, tak další dva už se neroztočí. Pravděpodobnost takové havárie rozhodně není (pravděpodobnost havárie jednoho disku)^3.

[Andrej]

Samozřejmě se intenzita poruch během životnosti disků mění. Bral jsem prostě ryze obecné zadání ve stylu „máme pole nějakých disků, o kterých nic nevíme, jen tušíme, že poločas přežití je tolik a tolik“. Netvrdím, že by se takový výpočet dal použít v praxi. Měření společnosti Google koneckonců dopadla zcela jinak.

Pravděpodobnost takové havárie rozhodně není (pravděpodobnost havárie jednoho disku)^3.

Pravděpodobnost takové havárie během konkrétního dne rozhodně je (pravděpodobnost havárie jednoho disku během konkrétního dne)^3.

Každé tvrzení má své předpoklady a každý jev má svůj pravděpodobnostní prostor, do kterého patří. I drobná změna může vyústit v nesmysl.

Chtěl jsem prostě jen říct, že bez silných vnějších vlivů je téměř nemožné, aby v rozmezí jediného dne selhaly tři disky z cca deseti.

[Jiří (BoodOk) Kadeřávek]

Právě to během konkrétního dne je ten háček. Možná jsem to napsal špatně. Správně asi mělo být, že pravděpodobnost havárie pole nerovná se ...

Problém s disky v poli je, že nemusí selhat během jednoho dne. Stačí, aby selhaly během jednoho měsíce. Jinak řečeno, pokud Vám disk po pěti letech najednou odejde, pak je pravděpodobné, že kdykoliv byste jej v krátké době před havárií zastavil, už jej porostě neroztočíte, případně obsahuje vadné sektory. Takže, nemáte-li hot spare nebo hot swap a musíte stroj shodit, abyste jej zotavil z degraded módu, riskujete. Před shutdownem takového stroje je zapotřebí raději provést migraci dat z degradovaného pole, pokud neexistuje dost čerstvá záloha. A dále, občas pole při výpadku disku a následné rekonstrukci vyvádějí psí kusy. V dnešní době rádoby HW Raidů by se měl mít člověk na pozoru.

[Chulda]

No, s tou pravdepodobnosti je to jine podle casu, vic viz statistika disku na google, prelozeny(?) clanek jest na http://www.cdr.cz/

[Boo]

Ze tenhle site bezi na linuxu ? :))))) To se dalo cekat, sila GNU, nikdo nic negarantuje...

[victor8]

[Petr (DotaZ) Jakubec]

mnooo woprawdu ftypni.... stat se to na jinem OS, tak mi dozivotne budou vyplacet rentu, ne?

videl jsem celkem dost smluv kolem sw. a zaruky na data jsem proste nevidel nikde. NIKDE, tak si nech tyhle kecy...

[neldor]

Co se tyce sw tak ti nikdy nikdo nic negarantuje, prave naopak. Precti si libovolnou EULu, zvalst ty Microsofti jsou jen pro silne zaludky .

[waldo.pepper]

No bóže, nejste ani první ani poslední. Kdo dělá do IT ví, že se podobný kolaps se může stát a nedělá mu problém se s tím vyrovnat. Kdo nemístně radí a kritizuje na svůj exces ještě čeká. Hodně zdaru, pánové.

[eM.]

souhlas, kdyz se dari, tak se dari :)

[Zdeněk Štěpánek]

Asi takhle, kdyby jste mi to nepriznali tak si nevsimnu, maximalne bych si pomyslel neco o deja-vu.

Zdenek

[aubi]

To je ta samá troltovská "databáze", co padá Lukačovičovi? Není vám to blbý? Používat a propagovat moderní operační systém a přitom používat ostudnou amatérskou databázi?

Někdo tu psal, že po roce používání PostgreSQL s ním nemá problém. Já ji používám už pár let pro studenty (každá skupina má svou databázi, takže jich mám na stroji něco kolem 150). Vždy k plné spokojenosti.

Zkuste, prosím, zvážit opuštění mysql, vhodné pro amatéry. Nebo, prosím, napište, co vás na ní tak láká. Opravdu by mě zajímalo, co je na databázi, která toho na trhu umí nejmíň, tak přitažlivého.

[Filip Jirsák]

Už to na ní funguje a je postačující. Databáze se neopouštějí jen proto, že ji někdo označí za amatérskou a vymýšlí si, že toho umí nejmíň. Ostatně, ono PostgreSQL a Firebird také budou amatérské databáze, ne? Rozhodně nejsou komerční…

Mimochodem, iniciativě se meze nekladou – můžete vytvořit databázové schéma, upravit zdrojáky, otestovat, navrhnout a otestovat způsob migrace dat, a Leoš pak určitě zváží, zda na nějakou jinou databázi nepřejít

[Tomáš]

A vy jste chytrej nebo chytřejší než rádio?

[Max]

Typický příklad učitele, co všechno ví, všechno zná a všemu nejlíp rozumí. Takový člověk je vskutku objektivní a určitě ke všemu i tak přistupuje. Heh ... konec fantazírování :-/
Zdar Max

[Messa]

To je ta samá troltovská "databáze", co padá Lukačovičovi?

No já bych chtěl vidět tebe, jak se staráš o několikaterabytovou databázi A jak víš, že používá MySQL? Tedy pokud máme oba na mysli ty samé výpadky.

[freshmouse]

To je ta samá troltovská "databáze", co padá Lukačovičovi?

Pokud vím, tak ten měl problémy s disky (IBM).

A že by byla trotlovská, o tom nevím. Jak se to projevuje?

[stativ]

A že by byla trotlovská, o tom nevím. Jak se to projevuje?

Možná se netrefím, ale řekl bych že proto, že do ní každý trotl rýpe.

[Radim Kolář]

Databaze MYSQL ma velmi skalni fandy. Tem to proste nevymluvite. Na nekterych serverech mi kvuli webhostingu mysql bezi, ale nemam mysql instalaci, ktera nehazi obcasne chyby v datech v tabulkach myisam a musi se cas od casu spoustet program pro obnovu integrity tabulky, delaji to verze 4.1 i 5.

Ja to moc neresim, uzivatele maji mysql radi, chteji ji, plati za ni a maji si vlastni data zalohovat, pokud jsou pro ne dulezita. Webhosting je bez mysql neprodejny a vetsinou kdyz to spadne, tak o moc dat neprijdou, takze vetsina si toho ani nevsimne.

Pokud jim obcasne havarie mysql vadi, mohou prejit na pgsql. Ten mi jeste sam od sebe nehavaroval za poslednich 5 let tak aby poskodil data, a pri archivelog modu ztrati uzivatel pri havarii disku maximalne par poslednich minut. Cena za hosting pgsql s archivelog modem zalohovanim je pochopitelne vetsi nez cena za hosting mysql bez zaloh

[PaJaSoft]

Ahoj Radime, jeste pomerne nedavno bych se pod to podepsal, ale dnes uz nemohu - naprosto neumyslne se mi nekolikrat nezavisle na sobe rozsypaly databaze (nastesti s nedulezitymi daty) a to jsem je moc neskadlil... - jednou to byla PgSQL 7.3 (? - daty si nejsem jist), podruhe verze 8.0.X. Skutecne se moc tesim na multimaster replikace (az jednou budou... - uz mely byt kdysi v sedmicce dle far planu a dle aktualizovaneho planu mely byt stezejni vlastnosti osmicky hned pote, co byl dokoncen MSVC a WAL - no rekneme, ze mozna ve verzi 15 se toho coby duchodce dockam...)

[Filip Jirsák]

Vaše argumenty proti MySQL beru. „Nemam mysql instalaci, ktera nehazi obcasne chyby v datech v tabulkach myisam“ je argument od někoho, kdo databázi používá. Naproti tomu „to je ta samá troltovská "databáze", co padá Lukačovičovi?“ nebo „ostudná amatérská databáze“ je výkřik někoho, kdo možná žádnou databázi vživotě neviděl. Je snad oprávněné váš argument brát vážně ale výkřiky aubiho stručně okomentovat, aby to nemátlo případné neznalé náhodné čtenáře. Mimochodem, pokud zaměníte Linux a MySQL, jsou si tyto dva příspěvky velmi podobné. Proti FUDu vůči Linuxu se na tomhle server ohradí téměř každý, ale nevidím jediný důvod, proč někomu jinému měřit jiným metrem. To ještě nemusí znamenat, že jsem fanda jednoho nebo druhého. Jak už jsem tady psal, od MySQL k PostgreSQL už jsme přešel kdysi dávno, takže k fandům MySQL se budu počítat těžko – ale k tomu přechodu jsem měl důvody, ne pomluvy a pověry.

[MaT]

U Iva Lukačoviče, pokud si pamatuji, měli i Oracle...

[stanono]

Len tak na okraj cela wikipedia bezi na MySQL. Asi problem nie je celkom len v samotnej databaze, ale aj architekture systemu, sposobe zalohovania, konfiguracnych nastaveniach a znalostiach adminov.

http://meta.wikimedia.org/wiki/Wikimedia_servers