Dotaz: sybase vs. ssd vs. btrfs

[EiFFeL]

Dobrý večer všem,

rád bych požádal o konzultaci, zda-li je vhodná kombinace uvedená v nadpisu? Pokud budu konkrétní, jedná se o 2 soubory velikosti > 10GB a průběžně narůstající log. Rád bych použil btrfs kvůli snapshotům a zálohování pomocí nich. Nejsem si ale bohužel jistý, zda-li copy on write filesystém bude pro práci s takto velkými soubory vhodný navíc ještě v kombinaci se ssd v raid1.

Máte někdo zkušenosti s btrfs a velkými soubory s průběžně narůstající velikostí? Předem děkuji za každou radu či zkušenost

Odpovědi

[lertimir]

Jednak si myslím, že dělat snapshot na urovni filesystemu a z něho zálohu je pro zálohování databáze zásadně špatně. Databáze se zálohuje prostředky databázového stroje. Za druhé když si představím, že databáze pracuje se záznamy lineárně v svém databázovém souboru, to se přeloží do logických bloků disku file systémem, a potom se to stejně ještě jednou přeloží řadičem SSD na paměťové buňky, které se fakticky použijí. A ještě v případě COW se data na úrovni logických bloků zapisuje jinam a tím pádem se soubor v té logické rovině fragmentuje, tak bych hledal, jestli databáze může jet přímo na oddílu blokového zařízení bez filesystému a ať si management bloků udělá sama. V případě SSD bych nějakou odpovídající část SSD nerozdělil do oddílů, ať má řadič SSD dost místa na optimalizaci.

[EiFFeL]

uznávám že s tím snapshotem pro zálohu jsem se nechal trošku unést, nicméně v případě sybase si nejsem zcela jist jestli aktuálně nasazená verze vůbec umí něco takového jako přímý přístup k blokovému zařízení

[Heron]

a z něho zálohu je pro zálohování databáze zásadně špatně

Proč by to mělo být zásadně špatně? Před nějakou potenciálně nebezpečnou operací si udělá snapshot (záležitost 1s) a kdy operace nevyjde, tak udělá snapshot té zálohy do původního umístění (opět 1s) a je ve stejném stavu jako před nebezpečnou operací.

Kdyby měl dělat dump, tak u x desítek GB je to už časově náročnější. Záloha se dá dělat online (potom je čas zálohy nulový), ale stále by se čekalo na obnovení těch x desítek GB.

Pro tyto případy jsou snapshoty to nejlepší řešení.

Pokud se jedná o dlouhodobou zálohu (archiv), tak je vhodné použít prostředky DB systému.

[lertimir]

Určitě máš větší produkční zkušenosti než já, tak připomínku beru. Snapshot bych ale stejně dělal jen za podmínky zastavené databáze. (zastavit-snapshotnout-spustit). S popisu jsem spíše očekával, že bude snapshotovat kontinuelně jedoucí databázi. Možná neoprávněně, ale mám vždy velkou obavu z jakýchkoliv operací na otevřeném filesystému, což snapshot FS s jedoucí databázi tedy pro mne je.

[Heron]

Snapshoty DB lze pořizovat za běhu. DB spuštěná na daném snapshotu je potom ve stavu poslední potvrzené transkace (a při startu proběhne recovery, stejně jako v případě výpadku proudu - pro ten db software zcela běžná situace a dokonce některé nabízejí rychlé módy vypnutí, kdy se xlog nevyprazdňuje do datových souborů, ale toto se odloží na příští start).

(Bavíme se o situaci, kdy má db všechna data na stejném subvolume - tedy nejtipičtější nasazení. Nelze snapshotovat x subvolume - např pro každý tablespace zvláť - snap nelze provést na všech atomicky ve stejný čas.)

Pochopitelně, i když pořizovat snapshoty lze, tak to není návod jak řešit běžné provozní zálohy. Každý DB systém nabízí lepší prostředky (online backup, nebo rovnou replikace), jak si se zálohou poradit. Pokud to db systém nenabízí, tak to lze řešit i snapshoty. Lepší než nic, lepší než mít jen sql dumpy (což je pro velikosti x desítek GB už na hranici použitelnosti).

mám vždy velkou obavu z jakýchkoliv operací na otevřeném filesystému

V tomto případě (BTRFS) se ale nejedná o otevřený FS. Nehrajeme si s blokovým zařízením (třeba LV), nad kterým je nějaký FS (který ještě navíc není připraven na běh na chytřejším blokovém manageru, což třeba ext4 a xfs je, takže i snapshot LVM informuje FS a FS se připraví (xfs_freeze) na snapshot). V případě BTRFS snapshotů je to vlastno přímo toho FS, takže FS je na to připraven.

Na tom FS jsou otevřené soubory. To ale nevadí, DB při každém potvrzení transakce udělá na vše nutné fdatasync. To znamená, že snapshot je pořízený v pořádku mezi dvěma fsync.

[smajl]

Ked uz si chcete bastlit sami zalohovanie/snapshotovanie databaze, tak podla moznosti konzultujte s DB administratom pouzitie "quiesce/unquiesce". Pocas toho mozete snapshotovat hoci aj vsetky disky naraz/postupne a na konci sa spravi unquiesce (quiesce release).

[Heron]

Velikost souborů vůbec nevadí, právě naopak, snapshoty dávají pro velké soubory smysl (snapshot je hotový do 1s, za jak dlouho zkopírujete x desítek GB?)

Mám zkušenosti s 600GB DB na BTRFS, tam jsem ale snapshoty nedělal (resp nepoužil pro provozní úkony - snapy tam jsou).

Běžně dělám snapshoty cca 35GB dat, mám (těch snapů) v průběhu roku už 21 a několikrát jsem se i vracel (vrácení znamená pořízení snapshotu toho zálohovacího snapshotu na původní umístění), vůbec žádný problém, naopak mi to poskytuje výhodu s tím dělat "psí kusy".

Snapshoty jsou hotové do 1s, kontejner nabootuje asi za 20s, takže když se něco pokazím, tam návrat do původního stavu znamená 22s navíc. Což jde. Obnovit 40GB by trvalo déle.

[pavele]

No nevím, na kontejnery bych měl strach to dát.

Ale na zálohy to bude pro mne asi to pravé.

[Heron]

Takových výkřiků na netu je.

Kontejner není nic jiného než oddělení procesů (a dalších věcí) v jádře. Pokud běží nad subvolume (což je výhodné), tak z hlediska to fs je jedno, zda ten proces běží přímo na jádře, nebo v nějakém odděleném namespace. Ty procesy nad daným subvolume mohou běžet přímo i bez kontejnerů.

Možná tam Docker dělá nějaké šílenosti (nevím, sám používám nspawn), ale samotná kontejnerizace procesů nemá na fs vliv.

[Heron]

Autor: Adam Štrauch

Aha, tak tím se to vysvětluje.

[pavele]

Myslíš tím přísloví "Šít horkou jehlou"?.

[Heron]

Štraucha znám jen jako autora na rootu, kde byl schopen napsat článek na libovolné téma a vůbec mu nevadilo, že tomu nerozumí, že je to povrchní* a že tam jsou chyby (to rootu nevadí dodnes, viz seriál o JavaFX).

*) Což je pochopitelné, aby člověk mohl napsat odborný článek, musí mít s danou věcí praktické zkušenosti a samotný článek zabere spoustu času. Není prostě možné chrlit desítky článků na široké spektrum odborných témat ročně.

Jestli tímto způsobem řeší i roští.cz nevím, ale ten článek nese všechny výše popsané atributy ("nerozumím tomu, ale to mi nezabrání to udělat").

[pavele]

Hm, uvítal bych nějaký článek o btrfs.

Pokud vím, tak ty používáš poměrně "blbuvzdorné" řešení.

Nesnáším ty výkřiky "btrfs rulez" od nejmenovaných uživatelů právě z výše uvedených důvodů. Myslím, že moc lidí nemá skutečné zkušenosti z praxe s tímto souborovým systémem.

Nechtěl bys někdy něco napsat pro sprostý lid, tak nějak po lopatě?

[Heron]

Co máš konkrétně na mysli? Napsal jsem články dva články pro ABCLinuxu o teorii, praxi a na svůj blog (odkaz v patičce komentáře) píšu další věci z běžného používání (stačí vyhledat rubriku BTRFS).

Dalšímu článku se nebráním, pokud jsem něco vynechal nebo něco není srozumitelné, tak sem s tím a zamyslím se nad tím.

[pavele]

Třeba nikde se neřeší slabiny btrfs, obnova, vhodnost použití - databáze a záloha velkých souborů (kvm), verze - jiný bude btrfs v Debianu stable nebo CentOS a jiný v poslední Fedoře nebo Debianu testing. Zkušenosti s tvrdým restartem v porovnání s ext4, porovnání rychlosti/vhodnost na RAID.

[Aleš Kapica]

Ale řeší, jenom to chce trochu hledat, víš? Jde totiž o to, že se většinou řeší konkrétní situace.

Zpracovávat verze by distro je blbost - vždy totiž záleží na verzích kernelu a ne distribuci. Chceš-li to srovnávat s ext4, pak se chystáš srovnávat nesrovnatelné. Na to, abys někde sepsal a porovnal vlastnosti FS musíš mít zkušenosti a čas. Ty nemáš to první a my to druhé. Za blogy a dobrou vůli nás nikdo neplatí.

[Heron]

Spoustu věcí na své wikině řeší Aleš daleko za hranicí kam já aktuálně mohu jít (on má větší nasazení v produkci )

Slabiny, obnova, vhodnost - jo, o tom bych mohl něco ublognout. Ono je to jako vždy: něco za něco. Něco se získá, něco se ztratí. Potom je jen na analýze, zda více získáme, než ztratíme.

Zkušenosti s tvrdým restartem - nemohu sloužit, tvrdé restarty neprovozuju. Podle mě je kravina se pokoušet o nějakou obnovu dat z důkladně rozbitého fs (pokud se rozbije jedno jak), je vždy nutné mít zálohu a po havárii spolehlivě obnovit data ze zálohy.

Na dost podobné otázky se lidé ptali už u článků LVM, co dělat, když se to rozbije apod. Mějte zálohy, naučte se obnovovat, natrénujte si to. Bude se to hodit nejen pro opravu rozbitého FS a LVM .

Rozbitý BTRFS jsem nikdy nezažil. Nepočítám případ backportovaného BTRFS na CentOS 5 (jádro 2.6.18), kde nezafungoval multidevice a nepočítám případ s vadným paměťovým modulem (na který jsem přišel díky BTRFS, protože psal do logu chyby CSUM - data byla poškozená, BTRFS to zjistil, na základě testů HW jsem přišel na vadnou ram).

[bohyn]

Doporucuji tuto prednasku: LinuxDays 2015 - Výkon PostgreSQL na EXT4, XFS, F2FS, BTRFS a ZFS - Tomáš Vondra, prezentace

Tyka se to sice primarne ZFS, ale je tam i BTRFS a dalsi FS.

Zalezi jaky ocekavas vykon a kolik transakci budes mit.