Report o ztrátě dat aneb proč nemám rád MySQL

Bylo nebylo, za devatero webservery byla jedna větší než malá databáze…

Příběh první

Aplikace byla psaná na míru MySQL a, což je podstatné, výužívala úložné enginy MYISAM i InnoDB. Nu což, produkt se chlubí tím, že si lze vybrat engine dle potřeb.

Což je featura sice na první pohled hezká, ale z hlediska ladění výkonu serveru naprosto šílená.

Provoz aplikace byl však narušován nebezpečným delikventem, totiž procesem zálohování, který úmyslně brzdil i okolní obyvatele serverovny. Klasické zálohování pomocí mysqldump si, z pochopitelných důvodů, zamyká tabulky. Toto zamčení však pravidelně způsobovalo nedostupnost a provozovatele oné aplikace znervózňovalo.

Při použití MYISAM nelze použít zálohování pomocí transakcí a je nutno tabulky zamykat. Aplikace potom do těchto tabulek nemůže zapisovat a fakticky je tak po dobu zálohování znemožněna její činnost.

Inu, vymyslelo se řešení. MySQL se chlubí tím, že podporuje (jistě triviálně implementovatelnou věc) a to replikace. Tak se z databázového serveru stal pán, který tak podřadnou práci, kterou zálohování dat nesporně je, přenechal svému otroku.

MySQL se chlubí tím, že podporuje replikace, v praxi je však nutné používat tuto funkci velmi obezřetně. Je nutno používat pouze engine InnoDB v určitém nastavení a funguje to až od některé verze.

Život plynul a stalo se, že pán ochořel a vládu nad panstvím musel převzít jeho otrok, který se stal novým pánem. Jenže zjistilo se, že pán několik měsíců řádně neinformoval svého otroka a tedy otrok neměl zcela aktuální informace. Dokonce i zlotřilý zálohovací proces, který tak původně narušoval funkce pána, ukládal stále tytéž, několik měsíců staré informace, které mu svědomitě předával otrok.

Replikace se ráda rozbije. Lidé kolem MySQL to berou jako vlastnost a i v tlustých knížkách se bere za standard neustálá kontrola správnosti replikace. V tomto případě se zálohovalo ze slave serveru, který ale mnoho měsíců nebyl synchronní s masterem. Takže zálohy byly k ničemu.

Příběh druhý

Na jiném, chudším místě, si pán nemohl svého otroka dovolit, tak musel hovořit se zloduchem zálohovačem sám.  I tento pán se odebral ke svému stvořiteli a tak přišla na řadu data schraňovaná zálohovačem.

Data zálohy byla v pořádku.

Leč při stavbě nového panství nebyli stavitelé dostatečně obezřetní a zasahovali na místa, která jsou běžnému smrtelníku zapovězena, za což byli po zásluze potrestáni.

Po inicializaci souborů InnoDB se na některé konfigurační volby nesmí sahat. MySQL však bez problémů nastartuje, jen bez podpory InnoDB. Pro administrátora služba v pořádku běží a nemá důvod to dále kontrolovat.

Do nového panství, po jeho slavnostním otevření a uvedení všech slavnostních hostů, přišel, jak jinak než zadním vchodem, i lotr obnovovač ze zálohovačovi tlupy. Ujal se své práce a data obnovil. Nový pán mu poděkoval a obnovovač šel o zemi dál.

Obnova ze zálohy, kde probíhají příkazy typu CREATE TABLE … ENGINE=InnoDB projde bez chybičky, i když žádaný typ databáze nepodporuje. Prostě se vytvoří tabulka výchozího typu. 

Na panství se pylně pracovalo, výsledky práce však nebyly takové, jak bylo dobrým zvykem za starého pána.

Aplikace posílala příkazy typu BEGIN, COMMIT a pro tento příběh důležitý zejména ROLLBACK, ale MySQL tyto příkazy tiše ignorovala, přestože tabulky byly typu MYISAM nepodporující transakce.

Závěr

Teď už pokud možno normální řečí :-)

Z předchozího je asi jasné, jak se stalo, že nemám rád MySQL. Na spoustě míst se dělo něco nepravého:

  • nefunkční replikace
  • nenastartování InnoDB z důvodu změny konfigurace, avšak služba normálně běží
  • ignorování typu tabulky při jejím vytváření
  • ignorování transakčních příkazů

, ale MySQL zarytě mlčí a data se kazí a kazí. V zásadě bych na každém místě předchozího seznamu očekával chybovou hlášku. Pokud konfigurační soubory neodpovídají datovým souborům na disku, nemůže ta služba nastartovat. Pokud už teda nastartuje (přimhouřím jedno oko) a při vytváření tabulky je požadován engine, který je nedostupný, opět ten příkaz musí vrátit chybu. MySQL v těchto případech chyby nehlásí a ani admin ani uživatel, nemá jedinnou informaci o tom, že je něco hodně špatně a tedy důvod se o to zajímat více.

Zejména tiché ignorování příkazu ROLLBACK, kdy aplikace očekává vrácení celé sady změn, není hodné produktu, který se chce nazývat (relační, acid) databází.

Na tom všem je nejhorší tichý zabiják dat (silent data corruption), kdy vše zdánlivě funguje, ale občas se vyskytnou neočekávané stavy. Až si toho někdo všimne pořádně (za pár měsíců), jsou data nenávratně poškozená i na zálohách.

 

Příspěvek byl publikován v rubrice Databáze, MySQL. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

1 komentář u Report o ztrátě dat aneb proč nemám rád MySQL

  1. Pingback: Money for Nothing | Heronovo

Komentáře nejsou povoleny.