Vlákno názorů k článku Orchestrujeme pragmaticky: bez zbytečných nástrojů, s pomocí rsync od [object Object] - Zastavovat DB pro zalohy? Od nas se chce...
-
![[object Object]](https://i.iinfo.cz/sh/profile/avatar/avatar-default.gif)
Zastavovat DB pro zalohy? Od nas se chce nedosazitelnych pet devitek, ne devet petek.
Jde to i lepe, staci udelat LVM snapshot a rsyncnout to z nej. Taky kdyz delam zalohy, tak snapshotuji starsi verze na cilovem stroji. Hodi se to: kdyz se vam smaze cast DB a vy si to nevsimnete, tak jinak prijdete o moznost to obnovit.
-
Martin X (neregistrovaný)
A co prepnut DB do backup modu (DB je online aj ked so znizenym vykonom, zapisuje sa len do redo logov, tablespaces su konzistentne) nasledne urobit snapshot (na fs alebo na diskovom poli), databazu prepnut naspat do "normalneho" modu a rsync robit zo snapshotu. Nasledne sa zbackupuju aj archivovane redo logy. Takto sa to bezne robi v profesionalnych rieseniach kde "zbyva jen modlit se ze nenastane to jedno procento kdy zaloha nebude konzistentni" nie je akceptovatelne.
29. 1. 2020, 11:29 editováno autorem komentáře
-
Martin X (neregistrovaný)
Ano, je pravda, ze vacsina projektov na ktorych som pracoval pouzivala Oracle DB. Okrem Oracle ma podobnu fukcionalitu aj DB2.
PostgreSQL az tak dobre nepoznam, ale nasiel som funkcie pg_start_backup() a pg_stop_backup(), teda urcita forma pripravy na online backup a jeho ukoncenie, existuje aj tam. -
Je to uz nejaky rok co jsem delal admina ale je nesmysl ze pokud je oracle v backup modu tak se zapisuje jen do redo logu. Samozrejme se zapisuje i do tablespace.
https://www.datavail.com/blog/oracle-tablespace-hot-backup-mode-revisited/
-
J ouda (neregistrovaný)
Nejsnadnější least effort řešení by asi bylo (mysql/percona) před rsyncem tam pustit xtrabackup (klidně i v režinu jednou týdně full, jednou za X incremental, mazat starší než 8 dní aby tam alespoň jeden full vždycky byl), ten rsyncovat, a na cílovém stroji si připravit script na rozbalení (které i když se jede přes inkrementálky je mnohem rychlejší než hledání syntaxe v manu ;-) )
Pravda zabere to o trochu víc místa na disku, ale v článku popisovaném use case nepočítám s tak obrovskými databízemi aby to byl problém. -
Myslim si, ze LVM snapshot bude fundamentalne rovnako poskodeny, ako keby sa kopirovali zive data. Aj keby sa spravil trojity odpichnuty flushberger, stale nie je zarucene, ze nejaka aplikacia nema nabuffrovane data v aplikacnej pamati a subory na disku su aj tak nekonzistentne. Co je mimo ine aj dovod, preco vacsina FS nejournaluje data, ale iba metadata. Neexistuje sposob ako povedat, ze data su konzistentne. Aj ak nejake bariery v API existuju, drviva vacsina aplikacii ich nepouziva.
-
Filip JirsákStříbrný podporovatelZáleží to na konkrétní aplikaci. Např. databázové servery jsou dělané tak, že když počítač v kterémkoli okamžiku přijde o napájení a na disku tedy tím pádem zůstane zapsané to, co tam v danou chvíli bylo, nedojde k poškození dat. Případně i tak, aby byla v databázi zapsaná i poslední potvrzená transakce – pokud je správně nastavený ovladač souborového systému a samotný disk (nebo RAID), tj. aby na disku bylo zapsané skutečně to, co si databáze myslí, že zapsané je.
Nebo-li nedá se obecně říci, zda data mohou být poškozena nebo nemohou – záleží na tom, zda s takovou situací aplikace počítá a zápisy na disk a fsync řadí tak, aby data na disku byla vždy v konzistentním stavu.
Ještě drobnost, nepoužíval bych termín „poškozená“, ale „nekonzistentní“. Ona při tom ustřižení napájení (nebo vytvoření snapshotu nezávisle na databázi) budou poškozená i ta data transakční databáze, která s takovým výpadkem počítá – data nebudou ve stavu, v jakém by měla být při vypnutém databázovém stroji. Rozdíl je v tom, že databáze se z takového stavu dokáže plnohodnotně obnovit a třeba dotočit transakce, které má zatím zapsané jen v transakčním logu ale ještě je nemá propsané do datových struktur.
-
Tu sa bohuzial dopustate extrapolacie nespravnym smerom. Predpokladate, ze na zaklade toho, ze transakcne databazy su nadizajnovane tak, ze v pripade vypadku data neostanu poskodene, ale staci prehrat transakcny log, je to tak u kazdej aplikacie.
Takyto pristup moze vyustit v smutne zistenie, ak sa na serveri bude prevadzkovat nejaka aplikacia, ktora takto tolerantna nie je, resp. nie je full-ACID. Ak mi na serveri bezi bohata zmes aplikacii, musim predpokladat, ze tam je aspon jedna aplikacia, ktora sa takto nechova a tym padom sa takto nechova system ako celok.
-
Filip JirsákStříbrný podporovatel
Predpokladate, ze […] je to tak u kazdej aplikacie.
Právě naopak, výslovně jsem upozorňoval na to, že je to speciální vlastnost transakčních databází, a většina jiných aplikací se tak nechová. -
Filip JirsákStříbrný podporovatel
Jsou i jiné způsoby použití počítačů (a souborových systémů), než weby nad transakční DB. Myslím, že je potřeba říci, že záleží aplikaci od aplikace, zda je připravená na tvrdé vypnutí počítače nebo není. Ano, zdánlivě je to samozřejmé tvrzení, bohužel je potřeba to napsat, když se v diskusi objevují jak tvrzení, že snapshot zaručí konzistentní zálohu jakékoli aplikace, tak tvrzení, že že snapshot nezaručí konzistentní zálohu u žádné aplikace. Pak je potřeba napsat, že pravda není ani jedno, že to záleží na konkrétní aplikaci.
-
Martin X (neregistrovaný)
Co sa tyka konzistentnosti samotneho fs v pripade snapshotu na urovni LVM alebo dokonca diskoveho pola, tak jfs2 ma v AIXe zaujimavu moznost a to pouzitim prikazu "chfs -a freeze ... " sa filesystem "zmrazi", teda sa urobi "flush" dat z cache na disk a na kratku dobu (nastavitelnu parametrom "timeout"), nutnu na vytvorenie snapshotu, sa pozastavia zapisy do fs. Pravdepodobnost, ze vysledny snapshot bude konzistentny, sa tak dost vyrazne zvysuje (aj ked 100% istota ani tu nie je zarucena).
-
Možnost freeze má vícero fs (třeba XFS) a LVM při snapshotu posílá info FS, aby se alespoň zapsal journal (extX), nebo rovnou freeze (XFS).
Ale nejlepší je používat FS přímo s podporou snapshotů, protože ten fs má veškeré informace o aktivitě a umí udělat atomický snapshot ve vhodnou chvíli (dokončení všech zápisů apod.)
Nebo mít data v DB, dobře zacházet s transakcemi a tedy mít v každém okamžiku po potvrzení transakce konzistentní data. A k zálohování DB používat nástroje k tomu určené.
-
Martin X (neregistrovaný)
V niektorych rieseniach sa jednoducho musia pouzivat snapshoty priamo na diskovych poliach a treba preto riesit aj konzistentnost snapshotov na urovni fs (a samozrejme aj na urovni aplikacie/DB).
Napriklad backup velkych, DB kde je backup okno relativne kratke (aj online backup je zatazou na resource stroja, kde DB bezi a preto by sa mal vykonat co najrychlejsie) sa backup robi tak, ze sa snapshot exportuje na diskovom poli na iny stroj, kde sa snapshot namountuje a z neho sa potom vykonava samotny backup. -
Martin X (neregistrovaný)
Ak spadne nod pre FEM analyzu, nepotrebujem robit restore, data si viem dopocitat. Vzhladom k tomu, ze vacsina dat kvoli rychlosti vypoctov, je aj tak ulozena len v RAM, nemam ani co restorovat. Konecne vysledky FEM analyzy sa vsak do DB daju ulozit v pohode (a vyuzit tak vsetky vyhody pouzitia DB na perzistentne ukladanie), treba len zvolit vhodny datovy model.
https://arxiv.org/ftp/cs/papers/0701/0701159.pdf . -
tbStříbrný podporovatel
Skuste niekomu, komu prave spadol mesiac trvajuci vypocet povedat, ze to je jedno, data si vie predsa dopocitat. :)
V tomto pripade treba riesit skor checkpointing, nie backup. To sa ale nastastie da celkom lahko dosiahnut aj s nespolupracujucimi aplikaciami tak, ze sa zavru do virtualu, z ktoreho sa potom pravidelne robi snapshot, ktory sa v pripade potreby obnovi.
-
FS *nema* veskere informacie o aktivite. Ma iba tie informacie o aktivite, ktore mu niekto dorucil. Problem je v tom, ze sucastou tychto informacii nie je priznak, ci sucasny stav je "transakcne korektny". Napriklad ak aplikacia zapise 8MB blok do suboru, a tento zapis sa stihne flushnut niekam po FS, takze o nom FS vie a vie ho spracovat, FS nemoze vediet, ci k tomuto zapisu neprisluchaju nejake dalsie data, ktore napr. aplikacia prave pocita. A ak ich zapise, tak bude vysledny subor z pohladu aplikacie corrupnuty, pretoze nebude obsahovat data, ktore aplikacia prave pocita, ale aplikacia napr. musela flushnut data z predosleho vypoctu, aby mala dost prostriedkov na dalsie kolo vypoctov. Zaroven vsak prave zapisany blok prepisal informacie, ktore sa odkazovali na data, ktore este prepisane neboli.
Z pohladu FS je vsetko ok, pretoze predsa do snapshotu dal vsetko o com vedel, ze je on the fly. Z pohladu aplikacie su ale data odpad, pretoze cast dat zodpoveda starsej generacii informacie, nez zvysok. Vysledkom je corrupnuty subor bez ohladu na snahu.
Idea vsetko vkladat do DB (budem implicitne predpokladat transakcnu RDBMS) je jednoducho naivna. RDBMS (ale vo vseobecnosti akakolvek ACID capable databaza) je vhodna iba na limitovane mnozstvo use-caseov. Existuje mnoho pripadov, kedy ju mozne nie je pouzit bud z dovodu ohavnosti interface-u, alebo absolutne nevyhovujuceho vykonu.
TL;DR: Snazim sa len poukazat na to, ze fakt, ze snapshotovanie funguje na DB neznamena, ze je to vseliek. V skutocnosti je to skor vynimka, nez pravidlo.
-
Tohle jsme probírali na ABCLinuxu a nechce se mi sem opisovat všechno.
Ano, je jasné, že FS neví nic o interní povaze dat jednotlivých programů, ale to je asi zřejmé a není potřeba to explicitně psát.
Podstatné je to, že z řady: snapshot blokového zařízení mezi dvěma operacemi, lvm snapshot s upozorněním alespoň pomocí freeze a FS s podporou snapshotů je ten FS na tom nejlépe, protože má nejvíc informací.
Co se týče způsobu ukládání dat na fs jednotlivými programy, tak je řada docela dobrých best practices, například používat atomické operace, nejčastěji přejmenování. Tj ukládat do dočasného souboru a potom jej atomicky přejmenovat. Nebo používat zápis po blocích a dělat fdatasync. Tím dá program FS najevo, kde jsou ty "hranice transakcí".
A asi není potřeba argumentovat tím, že "když to program udělá blbě, tak to bude blbě". Cílem je psát správné programy. Ono i ty transakce v DB lze použít špatně. Ale to není argument proti transakcím. Tohle jsou všechno jen prostředky, pomocích kterých to lze napsat správně a následně bez obav používat třeba snapshoty fs.
-
No a tu sa dostaneme k tomu, co je este blbo napisana rozbita aplikacia a co je uz nicim nepodlozene a nerealisticke ocakavanie administratora.
Mnoho enterprise aplikacii sa dostalo do cloudu tak nejako tesne na konci svojej zivotnosti, v podstate su bezproblemovo funkcne a v tejto faze ich nikto zasadne nebude prepisovat, aby boli transactionally friendly (lebo to nemusi byt len o pridani par volani tu a tam).
