Názory k článku
Nefunguje blogovací systém (aktualizováno)
-
anonymnípokud nekdo zije v bludu 'mam to v raidu, jsem klidnej', necht v nem zije dal. kdo si svych/klientskych dat ceni, nespokoji se s raidem, byt by to byla treba 10ka.
a kdyz uz se tu kope do mysql - ta umi treba online replikaci dat na jiny stroj. a to i na nekolik soucasne. overeno, provereno, funguje k plne spokojenosti. nezkoumal sem, umi tohle ty tzv enterprise sql db? :) -
mm (neregistrovaný)Ta replikace funguje opravdu dobre. Take se mne to libi. Neznam databazi, kde by bylo mozne tak snadno a elegantne zprovoznit neco podobneho.
Ona to rada lidi jen nevi. A proto vykrikuje takove blaboly jako autor prispevku na ktery reagujete, pripadne se divi, ze v diskovem poli odesly 2 disky naraz... -
mm (neregistrovaný)Narazka nesmerovala k PITR. Smerovala k tomu, ze ackoliv jej MySQL neumi, lze situaci se ztratou rychle se menicich dat po ztrate celeho diskoveho pole pomerne snadno predejit tim, ze jsou data online replikovana na zalozni stroj - a tedy je zbytecne naznacovat, ze v pripade MySQL se nelze proti takovym havariim pojistit.
-
LENIN POWER! (neregistrovaný)replikace neni vsechno. nechrani pred chybami aplikace nebo administratora. Zaloha + transakcni logy je nejlepsi reseni. V pripade nehody, muzete databazi vratit trosku dozadu u oracle tomu rikaji flashback
http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm -
tatramat (neregistrovaný)ja jsem prece nikde nezminil, ze je replikace samospasitelna, ani ze bych to povazoval za reseni odpovidajici/srovnatelne s PITR - je me jasne, ze zalohovani je komplexni zalezitost. ale uvedl jsi priklad obnovy dat jednou technologii (a pritom si kopl do mysql). pouze jsem uvedl alternativu pro tu nakopnutou. a obe musi/meli by byt doplneny o dalsi techniky zalohovani, o tom neni sporu.
v jedne spolecnosti spravuji databazi dulezitych a velmi citlivych dat. z nepodstatnych duvodu ulozenych v mysql. krome toho, ze se zalohuji data davkove kazdy den/v ruzne hodiny/dle udalosti, replikuji se kaskadove na dalsi 3 stroje. v pripade vypadku hlavniho db stroje staci v aplikaci zmenit host adresu konstanty pripojeni k databazi a jede se dal. vypadek a ztrata dat: minimalni, spise zadna (provereno). vadny stroj se opravi a nasledne zapoji na konec retezce. prijde mi to jednoduche a perfektne funkcni. ze zkusenosti se vszk nemohu zbavit pocitu, ty uzasne predrazene technologie generuji klientovi dalsi a dalsi zbytecne naklady.
me 2 centy. -
Karel (neregistrovaný)Nevím jak to Oracle dělá, ale u zákazníků to bylo nastavené tak, že celá aplikace využívala několik serverů. Když libovolný z nich odešel, ostatní se o jeho práci podělili. Dokud neodešly všechny servery a všechny disková pole, aplikace fungovala bez zásahu člověka. Oproti tomu co jste popsal vy vydím výhodu v tom, že dodatečné servery nebyly mrtvá zátěž a v běžném provozu se dělily o práci.
A ještě jedna perlička, kterou jsem ale na vlastní oči neviděl: nějaká novější verze Oracle (10g?) už umí vytvářet gridy, do kterých se dají zapojovat i klasické stanice. Takže můžu mít jeden server a do gridu s ním zapojit všechna PC ve firmě. Za běžného provozu potáhne většinu zátěže server (protože ten grid takhle nastavím), v případě přetížení začnou více pracovat jednotlivá PC. Pokud server z nějakého důvodu umře, celou jeho funkci převezmou samostatná PC. A dokud těch neumře dostatečné množství, bude celá aplikace fungovat a data se neztratí. -
No tak treba ja spravuji spoustu instanci Informixovych DB serveru a online replikace je tam uz od verze 9, v 10 uz vyrazne vylepsena a v soucasne 11 privedena temer k dokonalosti :)
Chci jen rict ano umi a dokonce funguje i v opravdu obrovskych OLTP prostredich (2 TB dat, 4tisice online sezeni).
Ondra -
LENIN POWER! (neregistrovaný)Bezna praxe je hotove logy krome nechani kopie na masine s db prenaset na jiny stroj. Bezne se to tak dela. Musim rici ze jsem to nevidel jeste pouzite tak, ze by se hotove logy nikam neprenasely.
Standby databaze by ani byt nemusela, moc redologu na blog sajte mit nebudou takze jejich prehrani bude rychlovka. Oracle jede tak 1GB redo logu za 2 minuty, to by byla vice nez dostatecna rychlost obnovy. -
asi oraclu nebo o cem byla rec. Ja sam licencni podminky oraclu neznam tak dokonale abych mohl rici zda ma lenin pravdu ci ne.
kdyz mate oracle na druhem stroji permanentne down a jen ho nekolikrat denne mountnete a rollforwardujete logy a pak ho zase stopnete tak snad druhou licenci nepotrebujete, protoze ho uzivatele nemohou pouzivat. Ale ty licencni podminky se casem meni, takze je nutne si to overit. Driv to tak bylo. -
David Krch (neregistrovaný)Musim vas trosku opravit, pokud jde o licencovani Oracle. Je treba rozlisovat a)clustery, jako reseni pro zajisteni dostupnosti databazoveho serveru a b)standby databaze, replikace ci ruzne formy mirroringu poli - tedy reseni pro ochranu dat diky jejich ulozeni na vice mistech.
Obecne Oracle vyzaduje licence za kazdy server na kterem je jeho software nainstalovan a/nebo provozovan. (Tj. staci jedno z toho.) V mem vykladu i vypnuty server je porad server na kterem je Oracle nainstalovan.
V pripade reseni, kdy kazdy z obou serveru ma vlastni uloziste (at uz proto, ze jde o replikovane databaze, standby databazi synchronizujici se pomoci redo logu, nebo se prenos zmen provadi mirroringem prostredky diskovych poli] je vzdy treba licencovat oba servery.
V pripade failover clusteru postavenych nad SPOLECNYM ulozistem (tj. 2 servery nad spolecnym diskovym polem - coz by ale neresilo problem popisovany v clanku), je mozne v clusteru mit jeden server, ktery nebude nutne licencovat za predpokladu, ze na tomto serveru nebude Oracle provozovan vice nez 10 samostatnych dnu v roce. Pravidlo 10 dnu tedy existuje, ale podminkou je, ze oba servery sdili stejne pole. Naopak neni pravda, ze by zalozni server musel byt jinak fyzicky vypnuty - to je proti smyslu failover clusteru - na zaloznim serveru prece porad v clusteru musi bezet clusterware, ktery hlida primarni server a v pripade ze primarni server spadne, clusterware musi nahodit Oracle na zaloznim serveru.
Berte to ale prosim jen jako muj soukromy vyklad licencnich pravidel Oracle. -
anonymníPreto je najlepsie nedavat do RAIDu uplne rovnake disky. Napriklad kupit kazdy v inom obchode alebo kazdy iny typ. Problem je, ze dodavatelia znackovych serverov tam daju disky uplne rovnake, lisiace sa poslednym znakom serioveho cisla. Tak aspon pomoze dokupit neskor dalsie dva disky do druheho RAIDu a prehodit jeden z tych povodnych.
-
lm (neregistrovaný)Kurva, to co sa tu zase zisli za kokoti z celeho ceskoslovenska alebo co? vsetci vsetko viete, ale este ste vami popisovane riesenia ani nevidieli nie to este robili. Vysvetli mi ako chces riesit dodavku diskoveho riesenie ked ti ma dodavatel doviest dva racky plne diskov (300-500 kusov) to ma ist kazdy kupit do ineho obchodu? Ked uz vyslovujete slova ako PITR vs. mysql tak davam do pozornosti man mysqlbinlog.
Vypnite uz konecne notebooky, ktore vam kupili rodicia z uspor a v tom okamihu sa z vas stali tvrdi admini vsetkych enterprise produktov na svete, vylezte zo svojich detskych izieb a chodte sa nadychat cerstveho vzduchu do realneho sveta. -
Karell (neregistrovaný)No neznam presne statistiky, ale ohledne raidu jsem se setkal s pozorovanim, ze kdyz uz se vyskytne okolnost, ktera zrusi disk, tak vetsinou zrusi vsechny. Takze raid neni zrovna recept na vyssi spolehlivost vzhledem k tomu, ze ty disky jsou vedle sebe, pripojene do stejneho zeleza atd.
Ja sam mam zkusenost, ze odesel 1 disk z 5 kvuli prehrati, coz ale beru jako stastnou vyjimku z pravidla, protoze to teplo bylo samozrejme vsem... -
Karell (neregistrovaný)No jednak ten hw uz je starsiho data a byla na tom cerstva instalace debianu a uz to je taky nejaky patek, tak nezjistim, jake byly moznosti monitorovani. Navic jsem nemel zadnou zkusenost se scsi disky, takze jsem planoval az na dalsi den se poohlednout po nejakych utilitkach a pres noc to kleklo. Byl to vyrazeny kousek, ktery jsem poridil za par stovek protoze se mi libil, takze zadna velka skoda :-)
-
lobo (neregistrovaný)Terry Pratchett, Mort:
Vědci vypočetli, že pravděpodobnost existence něčeho tak vyjímečně nesmyslného je zhruba několik milionů ku jedné. Jenže mágové zase spočítali, že při pravděpodobnosti, že se nějaká věc může přihodit s pravděpodobností milion ku jedné, přihodí se pravidelně devětkrát z deseti případů...
ČLÁNKY DO MAILU