Hlavní navigace

Vlákno názorů k článku Nestřílejte specialisty aneb Co způsobilo rozsáhlý databázový výpadek v Alza.cz od sep - Jako DBA musim rict ze preferuju replikaci na...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 7. 2018 19:38

    sep (neregistrovaný)

    Jako DBA musim rict ze preferuju replikaci na urovni DB a ne diskovym polem. Pro ucely DR cele firmy je nicmene nutne mit i tuto moznost, vzdyt spoustu firem ma svuj byznyz zavisly i na souborech jednotlivych uzivatelu. Bohuzel to je fakt. Resil jsem korupce DB z X ruznych duvodu a na ruznych platformach a dodneska se zdraham rict jestli je lepsi Oracle, MSSQL, PostgreSQL nebo MySQL. Samotne DB systemy maji svoje bugy ktere napr. zpusobi korupci standby databaze kterou zjistite az pri pokusu o failover. To se testuje fakt dost blbe. Problemy maji samotne OS nebo jejich komponenty jako multipathing drivery apod. Lost write na storage je fakt blby a na TLogu v podstate neresitelny. Clovek se az na zaklade vlastnich zkusenosti dobere tem "spravnym" resenim. Protoze u DB plati ze verit se neda nicemu. Byt prilis optimisticky znamena ze jednou to padne na hubu. A vetsinou to schyta clovek ktery v dane firme zustal, naockovan optimismem sveho predchudce. V Alze je mozna 1 kriticka DB pro beh cele firmy a jeji nedostupnost muze nastartovat DR proceduru. Ale v korporatech je X systemu navzajem propojenych a dohromady kritickych, problem jednoho systemu DR proceduru nespusti, ale musi se resit in-place. Takze obecne rady nefunguji. Vsichni z nas kdo ctou LUPu si myslim jsou schopni sebereflexe a ze sve praxe si vybavi kde sami udelali chybu v navrhu nebo implementaci nejakeho systemu. Nekdy mam dojem ze vyse zminovani optimiste jsou ti co casto meni zamestnavatele, protoze jsou si vedomi svych lehkovaznych rozhodnuti a potencialnich problemu ktere by se mohli projevit, tak radeji "utecou" a pak tvrdi ze jejich design je ten osvedceny, protoze za jejich pusobeni (kratkeho) se u predchozich zamestnavatelu zadny problem neobjevil. Toz tak. Drzim palce vsem komu zatim jejich kriticky system nepadnul na hubu. Odpocitavani bezi...

  • 21. 7. 2018 12:24

    Cx (neregistrovaný)

    Jsem obyčejný devopák, ale kolem pár systémů jsem prošel a vždy byla limitujícím faktorem cena/čas. Když firma začíná s nějakým vývojem, tak neví, zda bude vůbec úspěšný. Během vývoje se z nezkušenosti nebo čistě z časového pressu udělají rozhodnutí, které jsou nekompatibilní s růstem služby. Nakonec skončíte s kódem za desítky, možná stovky milionů, který je závislý na jediném připojení k databázi. Interně je systém přes knihovny, frameworky, optimalizace i špatná rozhodnutí tak propojený s jednou databází, že není možné ho upravit, aby používal nějaké více failure friendly řešení. Máme databáze, které byly navrženy kolem replikačních algoritmů jako CouchDB nebo Hadoop, ale kód je tak prolezlý vazbami na jednu konkrétní databázi, že bez obrovských investic není možné s tím hnout. V týmu k tomu většinou ani není vůle a když už se někdo pokusí, dřív nebo později narazí a sám to nezvládne. Nakonec se prostě s nějakými problémy počítá. Když se to komunikuje správně, tak to moc škody neudělá.

  • 30. 7. 2018 12:07

    ajtik (neregistrovaný)

    Máte pravdu v tom že Multipath je na spoustu systémech problémovej, ale v případě Windows pokud je storage od renomovaného výrobce který dodal MPIO drivery jsou funkční. Provozoval jsem storage s FC kdy jsme postupně z 8 linek degradoval až na jednu a zase postupně zprovoznil všech 8 a jak OS kde byl boot form SAN tak databáze a aplikace s úložištěm na storage vše šlapalo jak mělo ani jedno selhání jen v logu zápis o nefunkční lince a atd. Stejně stabilní to bylo u RedHat a Centos, ale u Ubuntu to bylo tak 50:50 někdy neustál ztrátu jedné linky někdy ustál ztrátu poloviny linek. Taky záleží na FC HBA kdy Qlogic se mi zdál stabilnější než Emulex.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).