Hlavní navigace

Nestřílejte specialisty aneb Co způsobilo rozsáhlý databázový výpadek v Alza.cz

David Hlaváček

Databázový architekt popisuje, co způsobilo nedávný velký výpadek e-shopu Alza.cz.

Doba čtení: 7 minut

Text původně vyšel na LinkedIn profilu autora.

Přiznávám, že jsem poslední dobou vztahy s SQL komunitou dost flákal. Článků nula, veřejných přednášek taky nula (pár interních školení v Alze bylo), minimální účast na SQL Meetupech. Samotného mne to velmi mrzí, rád veřejně přednáším a setkávám se s komunitou, ale nedalo se nic dělat.

Při náhledu do mé pracovní docházky byste zjistili, že za uplynulé dva měsíce jsem odpracoval 498 hodin. Tím se rozhodně nechci chlubit, ale spíš sám sebe dát jako odstrašující příklad. Byly chvíle, kdy jsem opravdu mlel z posledního (zvlášť po čtyřicetihodinové šichtě), a přitom jsem si to užíval, protože mne moje práce jednoduše baví.

Stručně o výpadku centrální databáze

Možná jste jedni z těch, které postihl nedávný výpadek jednoho z centrálních databázových systémů Alzy a vaše objednávka nebyla včas doručena. Možná jste se o situaci dozvěděli z médií, možná vás toto zcela minulo (upřímná závist).

Z pochopitelných důvodů nemohu zacházet do velkých podrobností, ale přesto se pokusím nastínit situaci. Sám jsem v internetových médiích sledoval diskuze pod články, informující o databázovém výpadku, kde se celá řada „odborníků“ vyjadřovala o naší úrovni. Upřímně mne pobavil komentář znějící: „Doporučoval bych Alze zastřelit databázové specialisty“. Myšlenka je to zajímavá, avšak nebylo by to nic platné, protože databázoví specialisté problém nezpůsobili, pouze ho řešili.

Velké společnosti mají své kritické IT systémy, jejichž nedostupnost má na chod firmy fatální dopad. Pro takové systémy je obvykle navržena pokročilá HADR strategie (High Availability & Disaster Recovery) tak, aby byla minimalizována rizika nedostupnosti systému.

Je to prosté. Máte dvě misky vah. Na jednu misku kladete vše, co je třeba zřídit, abyste minimalizovali selhání na různých úrovních (HW, SW, prostředí), a na druhou misku kladete finanční nároky na taková řešení. Každé HADR řešení má své výhody a nevýhody, často existuje SPOF (Single Point of Failure) a jeho odstranění představuje další náklady. Pokud nemáte „neomezený“ rozpočet, je to o kompromisu. Jakou míru rizika akceptujete? Proti jakému typu selhání nebude váš systém odolný? V neposlední řadě je třeba si uvědomit, že databázový systém je jen část celku, a tak, jak zajišťujeme HADR pro DB, musíme do stejné míry zajistit to samé pro ostatní systémy.

Failover Cluster Instance
Autor: David Hlaváček, Alza.cz

Failover Cluster Instance

Pro zajištění HA/DR jednoho z hlavních DB systémů byla až donedávna použita technologie Failover Cluster Instance. Přestože se jedná o jednu z nejoblíbenějších technologií (ne-li nejoblíbenější a nejpoužívanější), má jeden zásadní problém, který bývá často akceptován nebo ignorován. SPOF je sdílený diskový prostor, na kterém má clusterovaná instance SQL Serveru uloženy v jediné kopii produkční databáze. Tento diskový prostor je jako zdroj clusteru přesouván mezi nody clusteru. Pokud selže aktivní node, Cluster Service se postará o přesun zdrojů na jiný z nodů, který se tím stává aktivním a převezme databáze na sdíleném disku. Co když ale selže sdílený disk?

Proti selhání diskového pole se samozřejmě pojistíte. Nepořídíte si nějaký sdílený NAS, co máte doma na filmy, ale enterprise-class řešení. Dodavatel vám samozřejmě bude tvrdit, že takové pole je odolné proti všem selháním, své tvrzení podepře prezentacemi a cenovou nabídkou, převyšující cenu rodinného domu za Prahou i s pozemkem. Kdyby přece jen došlo k selhání pole, můžete použít technologii zrcadlení na druhé pole a tak dále. Obě pole jsou samozřejmě osazena Write Intensive SSD disky. K rodinnému domu tak přikoupíte Teslu S pro sebe a Teslu 3 pro manželku.

Asi mi to nebudete věřit (protože mě samotnému se to zdá neuvěřitelné), ale ani po jednom a půl měsíci stále nemáme v ruce oficiální vyjádření od dodavatele, co se vlastně stalo. Ano, pole selhalo a důsledkem toho selhání bylo poškození jednoho ze souborů databáze (o tom později). Ale proč k selhání došlo?

K čemu tedy došlo

Zatím čistě neoficiálně nám bylo sděleno, a je to tedy v rovině spekulace, že byla příčinou softwarová chyba pole. Opět opakuji, že to není potvrzeno, ale pokud bych teoreticky navázal na tuto hypotézu, SQL Server iniciuje IO operaci zápisu na diskové pole, řadič pole má velmi rychlou cache, do které provede zápis, a toto potvrdí SQL Serveru. SQL Server počítá s tím, že operace zápisu proběhla a je trvalá.

Řadič vinou softwarové chyby selže, zápis na samotné disky neprovede, anebo zapíše data chybně. Pokud bych danou IO operaci zrcadlil z jednoho pole na druhé, s jistou mírou pravděpodobnosti by byla data stejným způsobem poškozena. Softwarová chyba následně způsobí selhání pole, které je restartováno. SQL Server po opětovném připojení databází provádí kontrolu a jejda, jeden ze souborů databáze je poškozen.

Kdybychom měli štěstí, došlo by k poškození datového souboru. To říkám proto, že lze velmi snadno detekovat, jaká část kterého souboru je poškozena, a ze záloh tuto část obnovit, aniž by bylo nutné obnovovat celou databázi. Tato možnost výrazně zkrátí případnou dobu obnovy. Kdybychom měli štěstí, došlo by k poškození některé menší databáze a ne „macka“ o velikosti mnoha TB.

Samozřejmě jsme mohli mít větší smůlu a mohlo dojít k poškození všech DB. Poškození bylo nalezeno v řádku transakčního logu, který se nacházel cca v 99 procentech celého souboru. No nenaštvalo by vás, kdybyste sledovali recovery proces databáze, který pak v 99 procentech selže? To, že byl poškozen transakční log, je problém, a to velký.

Můžete obnovit celou databázi, můžete obnovit filegroup, datový soubor, dokonce datovou stránku, ale s poškozeným transakčním logem prostě nic neuděláte. Takže máte na výběr. Buď se pokusíte chybu opravit, což může být časově náročný a výsledkem značně nejistý podnik, nebo začnete obnovovat databázi ze zálohy s tím, že přijdete o část dat rovnající se frekvenci zálohy transakčního logu.

Obnova databáze je proces limitovaný fyzikálními zákony. Znáte rychlost média, na kterém máte uloženy zálohy, znáte propustnost síťové cesty mezi médiem a serverem a znáte rychlost zápisu na disk. Z toho lze plus mínus odvodit, jak dlouho bude trvat obnova databáze o objemu mnoha TB.

S čím ale mnohdy nepočítáte, je rozhodovací proces běžně označovaný jako think time. Nejprve musí padnout rozhodnutí o tom, zda se vydáme cestou pokusu opravy, nebo obnovy. Obnova je jistá, ale časově náročná, oprava může být časově méně náročná, ale nejistá. Výsledek znáte – nedostupnost DB služeb byla zhruba 27 hodin.

Chybě se nedalo předejít

Pokud provozujete SQL Server jako clusterovanou instanci se sdíleným polem, musíte počítat s tím, že existuje možnost podobného selhání. Je vysoce pravděpodobné, že se s tímto typem problému nikdy nesetkáte.

Po boji je každý generál. Jestli bych při zpětném ohlédnutí něco udělal jinak? Ano, rozhodně. Pokud jste jeden z těch, kdo podobná katastrofální selhání řeší, je vysoce pravděpodobné, že dříve nebo později se dostanete do kanceláře společně s potentáty.

No, a tak se stane, že sedíte s předsedou představenstva, místopředsedou představenstva, IT řediteli, team leadery a sestavujete postup řešení situace. Situace je o to horší, že jsou to všechno ajťáci. Proč horší? Protože co ajťák, to vlastní názor. Pokud si najmete specialistu na oblast, ve které nevynikáte, vkládáte do něj důvěru a měli byste věřit tomu, že pro vás udělá to nejlepší, co je v jeho silách, v dobách dobrých i zlých.

V žádném případě nezpochybňuji roli krizového řízení, manažerů a team leaderů. Oni jsou vlastníci dat a mají tedy nezpochybnitelné právo rozhodnout o postupu řešení. Paradoxně však nejvyšší autoritou v dané situaci je ten specialista, obyčejný pěšák na šachovnici, čerpající ze svých znalostí a zkušeností, zná nejlepší postup. Problém je, když své autority nevyužije a neprosadí své řešení. Pravda, výsledek je stejný, ale cesta mohla být podstatně kratší. Toto považuji za své největší selhání.

Všechno zlé je pro něco dobré. Byl jsem velmi příjemně překvapen reakcí celé řady firem. Byli jsme kontaktováni jak dlouholetými obchodními partnery s nabídkou pomoci, tak firmami, které doposud našimi dodavateli nejsou. Byť se nacházíte v tíživé situaci, je příjemné vědět, že nejste ostatním lhostejní.

Bohužel přesný opak musím říci o společnosti Microsoft. Pokusili jsme se je kontaktovat s prosbou o pomoc při opravě transakčního logu. Bohužel přišla zamítavá odpověď s tím, že aktuálně nemají žádného experta k dispozici. To mi pouze potvrdilo dlouhodobě velmi špatnou úroveň jejich podpory.

Nedávno se mi opět podařilo objevit další dva bugy spojené s kompatibilitou Availability Group a CDC (o tom až v dalším článku). Po řádném nahlášení chyb se „inženýr“ Microsoftu z Indie v odpovědi zmohl pouze na zaslání odkazu na jakýsi článek blogu doufaje, že mne tím odbude. Když vidím finanční náklady, které Alza Microsoftu ročně platí za SQL Server a další software, k tomu připojím objem Microsoft licencí, které Alza prodá zákazníkům společně s počítači, je postup takto velkého partnera přinejmenším zklamáním.

EBF 2018 tip v článku řečníci Lupa

Abych však byl férový, musím podotknout, že Alza nemá aktivní Premier Support Microsoftu, a proto si nemůže bezodkladnou pomoc nárokovat. Věřím, že by úroveň podpory s aktivní Premier Support vypadala jinak.

Velké díky zaslouží též Paul Randal (www.sqlskills.com), jeden z největších odborníků na SQL Server a recovery databází. Téměř obratem mi potvrdil, že daná chyba v transakčním logu je neopravitelná a jedinou možností je obnova databáze.

Našli jste v článku chybu?