Dotaz: Nejvhodnější filesystem pro COW

[Bill Gates]

Hoj, řeším už podruhé následující problém. Kdysi jsem to řešil pomocí BTRFS ale nebylo to dlouhodobě použitelné, chcípalo to výkonnostně.

Mám mysql MYISAM (z historických důvodů vývoje projektu) databázi a využívám toho, že na úrovni databáze mohu dělat

1) stop databáze
2) cp /var/lib/mysql/[databaze] /zaloha/nekam/bokem/
3) start databáze
4) tar czf /zaloha/[databaze].tgz /zaloha/nekam/bokem/*
5) přenos jinam a užití snapshotu (třeba nahození nekonzistentního spadnutého replikačního slave z tohoto funkčního slave)

Kritický krok 2, který vyžaduje zastavit db server, aby data neměnil pod rukama během snapshotování strašně dlouho trvá.

Zde se tedy přímo nabízí copy on write a využití filesystemu, který COW umí. Pak je to otázka sekund. Co prosím by jste z vlastní zkušenosti doporučili za FS v dnešní době? Já to mám funkčně napsáno i s COW ale mám to na ext4, takže se mi teď tahle vlastnost neuplatňuje a trvá to a počítám s tím tak. Když jsem to dělal na BTRFS, začalo to nějak asi bobtnat a nedělal jsem něco co se s BTRFS dělat má a pak to už neměl čas studovat. Potřeboval bych nějaký FS který umí COW a nepotřebuje dál nějaký extra servis, nebo druhá varianta, potřebuju vědět co mám v takových případech použití dělat, aby FS stále svižně fungoval a nebobtnal. Ty zálohy dělané pomocí COW jsem vždy po zatarování samozřejmě smáznul. Tím by on měl nějak zahodit ty vazby mezi původním souborem a COW souborem a jet normálně dál ne? Nebo to bylo tím, že jsem samotnou tu databázi provozoval na BTRFS, což není dobré?

Díky za podněty a postřehy a případné nakopnutí.

Odpovědi

[Heron]

Doporučuju změnit DB, protože v normálních databázových systémem máte možnost udělat konzistentní dump za běhu, není třeba vypínat službu db k vůli záloze a je možné zálohovat i inkrementálně. Jinými slovy zvažte, jestli je možné přejít na jiný db server a zda tento přechod nebude levnější a do budoucna vám nepřinese lepší možností, než udržování tohoto pěti bodového skriptu.

Další věc je, že normální db se nemusí vypínat k vůli pořizování snapshotu. Takže klidně můžete snapshotovat i za běhu, databázový produkt splňující ACID se s tím v pohodě vyrovná (některým produktům můžete poslat hint, že teď se bude fotit, ale nemělo byt to být podmínkou).

Co se týče provozu DB nad BTRFS, tak kromě toho, že to bude pomalejší, žádné další problémy nenastanou. Zkrátka btrfs sub snap ; cp ; btrf sub del a je to. Za normálních okolností není potřeba dělat žádné další vyfikundace, btrfs si nahodí process cleaner a ten smazaný snapshot uklidí. Problém by mohl nastat pouze v případě, kdy by na to neměl čas (disk by byl tak zatížen, že zkrátka úklid trvá déle než intervaly mezi snapshotama).

[Bill Gates]

Zdravim, prakticky konzistentni dump za behu z podstaty veci bez nejake techniky zalozene na COW neudelame asi moc jinak nez leda zamcenim databaze nebo alespon tabulek pro operace zapisu, jinak je to jako snapshot virtualizovaneho OS za behu, coz taky jaksi moc nejde, potreba ho minimalne pozastavit.

Neni nutno hned stopnout server, to je jasne, pro me ucely pohodove staci LOCK, coz mam overeno. Nicmene pak se hromadi napriklad HTTP dotazy ve kterych se provadi update/insert/delete a tyto cekaji ale jsou drzeny. Samozrejme toto je lepsi chovani je hromadit a s mirne horsi odezvou je pak vsechny vyridit, nez proste uplnym stopnutim znepristupnit DB server webserveru uplne a uzivateli zobrazit nejakou chybovou hlasku misto chvilkoveho pozdrzeni. Ale to hromadeni jde tak na vterinu max, jinak to muze byt nebezpecne a padne to, tzn idealne COW, a par zlomku vteriny :) .

Dump jako takovy by byl taky docela chciply v porovnani s COW toho datoveho uloziste s ohledem taky na 4GB ktere ta databaze ma. Nezapomenme ze jsme na MYISAM a aplikace je narocna na prepis jen tak ze dne na den. Behem dumpu musime byt taky zamceni minimalne pro operace zapisu, jinak ten dump bude nekonzistentni takze taky cekame.

COW na datove uloziste toho DB serveru mi i s MYISAM prijde znacne rychla jak raketa. Jak dlouho pak trva archivace uz neni podstatne, dulezity je ten cas nezbytneho vypadku nebo zhorseni odezev, coz se mi u teto metody zda dobre...

Zkusim mozna jeste jednou BTRFS, treba se za ty roky neco vylepsilo ... Existuje jeste neco jakoby mainstreamoveho (tedy s nejakou uz vetsi komunitou a ne stagnujici skolni projekt) co by bylo doporuceni hodne a zaroven umi COW i krom BTRFS ?

[Jendа]

Zkusim mozna jeste jednou BTRFS, treba se za ty roky neco vylepsilo ...

Podle mě je to principiální problém. Můžeš zkusit zapnout autodefrag, ale nevím, jak moc to pomůže.

Existuje jeste neco jakoby mainstreamoveho (tedy s nejakou uz vetsi komunitou a ne stagnujici skolni projekt) co by bylo doporuceni hodne a zaroven umi COW i krom BTRFS ?

Vždyť to píšu - LVM snapshoty jsou CoW. A výhoda je, že se CoW dělá jenom v okamžiku, kdy tam ten snapshot je - takže v tvém případě jenom po dobu kopírování.

[Heron]

Vždyť to píšu - LVM snapshoty jsou CoW. A výhoda je, že se CoW dělá jenom v okamžiku, kdy tam ten snapshot je - takže v tvém případě jenom po dobu kopírování.

Něco podobného umí i BTRFS. Lze jej nastavit tak, aby COW neprováděl - a to jednak pro celý mountpoint nebo pro konkrétní adresář. chattr -C - musí se to nastavit na prázdný adresář před nakopírováním dat a potom všechny soubory mají příznak nocow. Snapshoty fungují (ten fs si ty cow dělá dál podle potřeby, ale nepoužívá je při každém zápisu tak jak normálně - takže je to rychlejší).

Některé instalátory (třeba postgresql) chattr -C volají na datový adresář při jeho vytváření.

[Heron]

prakticky konzistentni dump za behu z podstaty veci bez nejake techniky zalozene na COW neudelame

No právě proto jsem psal o výběru jiného db produktu. Protože to, co tady řešíte - tedy konzistentní zálohu za běhu systému - to jiné db zvládají levou zadní.

DB pracující na MVCC / MGA si něco jako cow implementují vnitřně (více generací dat; snapshoty), takže jsou schopné poskytnout konzistentní snímek dat.

Toto se vy pokoušíte naimplementovat z vnějšku té db. Možná se vám to podaří, ale je otázkou, za jakou cenu a s jakým výsledkem.

jinak je to jako snapshot virtualizovaneho OS za behu, coz taky jaksi moc nejde, potreba ho minimalne pozastavit

Nevím, proč by to nešlo, snapshotů vm za běhu děláme stovky denně.

Zkusim mozna jeste jednou BTRFS, treba se za ty roky neco vylepsilo ... Existuje jeste neco jakoby mainstreamoveho (tedy s nejakou uz vetsi komunitou a ne stagnujici skolni projekt) co by bylo doporuceni hodne a zaroven umi COW i krom BTRFS ?

Tak můžete zkusit zfsonlinux jestli chcete (nebo strčit mysql na freebsd), případně můžete zkusit LVM a dělat snapshoty LV - princip popsal lertimir, snapshoty LV se hodí právě na zálohování. (Akorát je s tím víc práce - udělat snapshot LV, připojit jej na mountpoint, vykopirovat data, odpojit, odstranit snapshot.)

[Michal Kubeček]

Kritický krok 2, který vyžaduje zastavit db server, aby data neměnil pod rukama během snapshotování strašně dlouho trvá. Zde se tedy přímo nabízí copy on write a využití filesystemu, který COW umí. Pak je to otázka sekund.

Někdo by možná řekl, že se spíš nabízí použití databáze, kterou není potřeba kvůli záloze úplně shodit.

[Bill Gates]

je to kompromis mezi narocnosti pripadneho prepsani / revize kodu vetsi aplikace. Prechod neni nerealny ale zatim si ho nedokazu predstavit, schudnejsi je ted mozna posunout se pomoci COW a pak kdyztak prechod, nejlepe az odpadnou extra zastarale ale stale pouzivane casti systemu, o to lepe... ale to ted neni uplne podstatne .. dulezite je nejaky dobry FS resici dobre COW.

[Jendа]

btrfs s CoW se při změnách uvnitř souborů, což databáze dělá, fragmentuje, a pak je to hrozné, na rotačním disku obzvlášť.

Co dát databázi na LV a dělat LVM snapshot?

[Filip Jirsák]

btrfs s CoW se při změnách uvnitř souborů, což databáze dělá, fragmentuje

Každý CoW souborový systém se při změnách uvnitř souborů fragmentuje – z principu CoW.

[myisam]

Proč to neobejdeš?

Udělej si master-slave nebo master-master, mysql to umí.

Zálohuj potom tu druhou databázi.

Záloha bude vždy konzistentní a nebudeš muset řešit souborové systémy.

[Michal Karas]

Vždyť přímo v dotazu píše, že tento postup musí provádět například tehdy, když ten slave spadne.

[jekub]

Obecně (jak psal myisam), replika a záloha repliky. Toho bych se držel.

Kritický krok 2, který vyžaduje zastavit db server, aby data neměnil pod rukama během snapshotování strašně dlouho trvá.

Chcete-li si hrát, prostoru je spousta. Kopírovat jen změny (změněné soubory) od poslední zálohy, partitioning, rsync.

Anebo (s MySQL nezkoušeno) zfs jako blokové zařízení, nad tím ext4.

[lertimir]

Myslím, že řešíte kvadraturu kruhu. COW filesystem z principu věci zapíše data jinam než jsou původní, což při individuálním zápisu kousků uvnitř souboru vytvoří stále větší fragmentaci. (jak psal už Filip) Databáze pracuje přesně takto a pak na rotačním disku vytvoří obrovsky fragmentovaný soubor. Databáze pracuje nejlépe, když ji FS do organizace moc nekecá, ne nadarmo některé DB jsou schopny pracovat i přímo na blokovém zařízení a vše se na něm řídí samy. Pokud není jiná možnost než práce se zálohou přímo na FS a ne prostředky DB, jsou jen 3 výsledky. Jednak zastavení a kopie souboru s nevyhodou dlouhého kopírovacího času, nebo btrfs snapshoty a obrovská fragmentace a popsané důsledky, nebo LVM snapshot a významné (ale patrně ne tak velké jako při btrfs fragmentaci) zpomalení pokud snapshot existuje. Tedy po celou dobu, kdy se zálohuje. LVM snapshot funguje tak, že v hlavním blokovém zařízení bude přímý zápis jako při standardním běhu, a jinam do jiného oddílu se kopírují původní data z oddílu. Tady na zápis bloku se v LVM snapshotu provede: čtení původního -> zápis původního jinam -> zápis nového na původní místo, včetně potřebných seeků. nisméně pokud jsou data v bloku již změněna tak stačí jen zápis nového.

[Michal Karas]

Taky se s tím problémem musím čas od času poprat.

Trochu zmírnit se to dá úpravou postupu:

1. rsync
2. lock & flush
3. rsync
4. unlock
5. ...

[mhepp]

Já nevím, je to celé takové na houby.

Jediné bezvýpadkové řešení je master-slave replikace a zálohování na slave. Tam už není potřeba výkon, nevadí, že se zastaví kvůli kopírování na úrovni souborů a tak dále... Navíc jako bonus získáte zálohu pro případ odstávky master, pokud replikaci postavíte jako master-master, máte velmi odolné řešení.

Takhle provozuji MySQL už pár let a zatím všechno vydržela. Replikace se dá nahodit s minimální odstávkou, a potom můžete za provozu přehodit úložiště z MyISAM na InnoDB. Zde je potřeba počítat s výkonnostním poklesem, ale je vykoupen vyšší jistotou konzistence dat.

Co se týče FS, když jsem nedávno instaloval postgres, tak jsem hledal doporučení vhodného FS a tam vyšel nejlépe XFS (dříve jsem se mu docela bránil, ale teď mi přijde jako lepší volba než ext4).

[Aleš Kapica]

..ale teď mi přijde jako lepší volba než ext4).

Do první ztráty dat. XFS má svoje specifika. Pokud jde o ext fs, tak osobně mám nejlepší zkušenosti s ext3.

[lertimir]

Souhlas. XFS drží v paměti velké množství metadat a pokud padne bez sychronizace, ať již pádem elektřiny a nebo pověšení systému, tak je FS těžce restaurovatelný.

[myisam]

No nevim.

Na XFS se v poslední době hodně zapracovalo a je výchozím FS v Centos 7.

Při testování se mi kupodivu zdál pomalejší než ext4.

Co se týče tvrdého ukončení XFS, před pár lety u něj docházelo k zajímavé věci - poškozený soubor se vyplnil nulama. Osobně otestováno (už to spravili).

Testoval jsem tvrdé ukončení a subjektivní "svižnost" systému na XFS, ext3, ext4, ext2, RaiserFS, JFS. Vždy čistá instalace a během vytažení ze zásuvky (10x) jsem nechal kopírovat nějaká data na disk. Nejlépe z toho vyšel (tehdy) ext3.

Ext4 (ne ext3!) měl zase bug - docházelo k poškození FS při použití v KVM virtualizaci.

Ovšem pro mě je XFS neocenitelný kvůli možnosti nastavit quotu na adresář (Samba).

Takže těžko radit, je potřeba si vše otestovat...

[mhepp]

Přesně tak, XFS dost vyrostlo a mají s ním veliké plány.

[dustin]

Pokud používáš pouze innodb, lze replikaci nahodit bez odstávky masteru (pokud je již pro replikaci nakonfigurovaný).

[mhepp]

Dřív bylo nutné do konfigurace mysql přidat pár voleb. Jako například povolit binární log, počet a offset masteru při master-master replikaci. To už není potřeba? Vím, že se pár věci měnilo, je to celkově jednodušší, ale už je to pár let...

[dustin]

Je, proto jsem psal "pokud je již pro replikaci nakonfigurovaný".