Aky file system pre DB server?

hknmtt

  • ***
  • 106
    • Zobrazit profil
    • E-mail
Aky file system pre DB server?
« kdy: 31. 08. 2024, 12:35:22 »
Ktory file system by ste odporucili na databazovy server(mysql, maria, postgres...)?

Pozeral som nejake videa kde sa porovnavalo asi 6 FS a najlepsie vysiel xfs a ext4. Ale napriklad btrfs som videl ze ma snapshoty a vie revertnut cely stav, co moze byt uzitocne?


alex6bbc

  • *****
  • 1 670
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #1 kdy: 31. 08. 2024, 13:03:48 »
neni i volba nechat partisnu bez filesystemu a db si to sama zpracuje?

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #2 kdy: 31. 08. 2024, 13:04:38 »
Rozdíl ve výkonu různých FS je třeba 30% podle typu FS. Ale obvykle ten výkon nepotřebuješ.
Chápeš, když potřebuješ převéz kyblík štěrku, nepotřebuješ kupovat sklápěčku.
Můžou převážit jiné výhody.
Naopak u milionu transakcí za minutu už výkon FS řešit chceš. Pak jde o důsledné oddělení DB a Transakčních logů, optimalizace na úrovni komfigurace DB, FS i tabulek.

alex6bbc

  • *****
  • 1 670
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #3 kdy: 31. 08. 2024, 13:06:13 »
bylo by zajimave zkusit in-memory databazi, nebo ji rozjet na partisnou vytvorenou z kusu ramky.

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #4 kdy: 31. 08. 2024, 13:40:12 »
bylo by zajimave zkusit in-memory databazi, nebo ji rozjet na partisnou vytvorenou z kusu ramky.

Máš InMemoryTable a jsou kua rychlé. Navíc tam nemáš to zbytečné IO okolo FS.
Ale to je věc programátora, aby to vymyslel.

DB na RAMdisku...jen pro rychlé přemrdlání dat a musí mít ECC...


Re:Aky file system pre DB server?
« Odpověď #5 kdy: 31. 08. 2024, 15:45:50 »
Desítky let (letí to) na databáze s řádově tisíci až desetitisíci tps používám xfs. Občas jsem zkoušel alternativu (kdysi třeba i jfs, později ext4, btrfs apod.) a zatím jsem se k němu vždy vrátil. Ale záleží možná na workloadu. HA a backupy (viz snapshoty) řeším prostředky databáze (replikace, pgbackrest).

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #6 kdy: 31. 08. 2024, 16:18:41 »
HA a backupy (viz snapshoty) řeším prostředky databáze (replikace, pgbackrest).

Což je asi to nejchytřejší, co můžeš udělat.
Ale není od věci mít i kompletní image/snapshoot z rána ;-)

Re:Aky file system pre DB server?
« Odpověď #7 kdy: 31. 08. 2024, 18:17:47 »
Ktory file system by ste odporucili na databazovy server(mysql, maria, postgres...)?

Pokud bych bez další znalosti konkrétního workloadu, aplikace a prostředí zvolit fs na standardní server s db, tak by to za mě bylo XFS.
Nejmíň problémů za léta používání (RHEL a klony, SUSE), dobrý, predikovatelný výkon. I většina kompletních systémů, co byla přednastavené a instalované dodavateli, používalo XFS a bylo s ním podporované.


Ale samozřejmě může být hromada dalších aspektů, které souvisí s konkrétním nasazením. Některé CoW fs (ZFS, BTRFS) můžou být za určitých podmínek lákavé, protože umožní flexibilní práci s vnitřními snapshoty a můžou rozšířit možnosti nebo zjednodušit zálohování. Na stranu druhou je tam typicky nutné daleko intenzivnější ladění s nastavením konkrétní databáze, protože se tam ve výchozím nastavení některé věci funkčně duplikují (WAL na databázi, CoW u FS atp.), což má za následek, mnohem víc zápisů než je nutné. To má pak samozřejmě vliv nejen výkon, ale i třeba na množství zápisů u SSD.
Plus některé kombinace se mohou chovat opravdu divně a přidělat vám spousty starostí (zkuste si pogooglit např. BTRFS +innodb +mysql +issues).
Takže to chce dobře rozmyslet a otestovat. Někdy nemusí být ten nižší výkon sám o sobě až takový problém (ne každého brzdí množství OLTP transakcí, záleží na struktuře databáze, aplikace), pokud to něco přinese jiné benefity, nicméně jestli to potom ohrozí spolehlivost a dostupnost systému, a projeví se to třeba až časem, už je to větší problém.

Zároveň, jak už tady zmínili ostatní, můžete mít třeba zálohování vyřešeno jinak.. např. logická záloha z repliky db, nebo nějakými inkrementálními zálohami za jízdy (hot backups), což třeba jde přes mariabackup z MariaDB, nebo u komerční MySQL enterprise.
Případně ty snapshoty na zálohování jdou implementovat i pod standardním XFS s pomocí LVM. Není to tak elegantní, musíte si dopředu spočítat, kolik na to bude potřeba místa, ale je to funkční a používá se to dekády.
Další možnost jsou pak třeba snapshoty celých virt. disků s databázovými soubory, pokud to rozběhnete na nějakém hypervizoru (ať už nějaké otevřené řešení, nebo například VMWare + Veeam). Typicky je tam nějaká plánovaná doba snapshotu, hypervizor zakomunikuje s vm, spustí uvnitř nějaký skript, který flushne db a zamkne pro zápis. Pak hypervizor udělá snapshot disku pro zálohu, a uvnitř vm spustí skript, který db zase odemkne.

Spousty možností, ale jak jsem psal, kdybych měl odpovědět úplně obecně, šel bych do XFS.

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #8 kdy: 31. 08. 2024, 19:09:28 »
šel bych do XFS

+1

https://www.phoronix.com/review/optane-linux-raid/4

XFS má právě docela dobrý výkon, hlavně když se to všechno trochu poladí.
Nicméně klidně EXT4 a všechno mít na jednom device, protože u 50 zápisů za minutu je to prostě fuk.
(Víc FS vs jediný? Jeden Device vs několik? Složitá konfigurace vs jednoduchá? Default parametry vs vytuněné? Vynaložené úsilí vs má to cenu?)

Já chápu, že takový Pavel Stěhule řeší asi úplně jiné hardcore úlohy, ale pro ten základ myslím dobré.
« Poslední změna: 31. 08. 2024, 19:15:11 od CPU »

Re:Aky file system pre DB server?
« Odpověď #9 kdy: 31. 08. 2024, 20:41:56 »
Snapshoty jsou příjemné, pohodlné. Pokud nemáte mnoho Tps, je to asi OK.
V principu ale, snapshoty jsou implementovány pomocí Copy on Write. Pouze pro změny se alokuje nové místo. Kde? No "někde jinde", bokem mimo stávající data. Databáze navíc nezapisuje lineárně, ale seekuje v zásadě náhodně. Výsledek za mě může být jediný: filesystém se tím obscénně zfragmentuje. A dále: když uloupnete snapshot, a provoz jedete dál do toho CoW, a následně odzálohovaný snapshot zrušíte, tak Vám zbydou právě ty CoW špagety. Nemám dost přehled, abych tohle dokázal tvrdit s jistotou, možná se proti tomuto chování dá v rámci FS nějak bojovat... (mohlo by se jednat o jeden z aspektů BTRFS rebalance?) ale je to velice častá námitka proti použití BTRFS pod databází.
Ono se v BTRFS to CoW chování dá zakázat pro běžný provoz bez snapshotů (= nedělej CoW když nemusíš) - ale zrovna snapshot je situace, kdy tenhle zákaz CoW implicitně padá, což je v dokumentaci zmíněno :-(

Re:Aky file system pre DB server?
« Odpověď #10 kdy: 31. 08. 2024, 20:54:11 »
BTW je to už mnoho let, co jsem trápil diskové subsystémy pomocí benchmarků - v té době s rotující rzí a direct-attached RAIDy jsem byl schopen, přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu, kdy na disk netekly žádné transakce, a jakýkoli syscall pro přístup k souborovému systému se zablokoval navěky. Prostě deadlock v kernelu. Nikde žádná chybová hláška, co nešahalo na disk to běželo dál, ale cokoli s diskem zůstalo viset.

V té době XFS a ReiserFS (Reiser 3) tenhle problém neměly, Bonnie++ vždycky proběhla celá, klidně jsem mohl spustit několik instancí simultánně.

hknmtt

  • ***
  • 106
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #11 kdy: 31. 08. 2024, 21:29:29 »
zda za ze bud ext4 alebo xfs tym ze ext4 je znacne rozsirenejsi tak je to bezpecna a solidna, a univerzalna, volba

https://www.youtube.com/watch?v=O9QZVzq-rX4

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #12 kdy: 31. 08. 2024, 21:39:33 »
přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu

Rozdíl mezi serverovými a desktopovými disky je třeba v tom, že ten serverový se ve stanovené době přestane pokoušet o přečtení chybného sektoru. (Desktop se snaží data zachránit. Serverový spoléhá na paritu Raidu, tak to vzdá.)
A teď rozdíl pole ze serverových a desktopových disků:
Pole ze serverových disků pokrčí rameny, dopočítá chybějící data a nějak se s tím vypořádá.
Pole z desktopových disků rameny nepokrčí, dopočítá chybějící data a začne na tom strašit.

Další problémy mohou nastat v případě, kdy je pole složeno z disků s nevhodnými firmware.
Taky jsem měl takové pole a dostat ho do úzkých nebylo až tak těžké.
Pole začalo kravit po vložení nového disku s novějším firmware!
Po nahrazení disku za starý disk (ze zásob) bylo chování pole opět normální.
(RAID 6+hotspare...byť se to tak nemá dělat, ale...)

Prostě dostat FS do úzkých pomocí databáze prostě často není tak těžké.

Jestli si to chcete zkusit, sežeňte si QLC disk s SLC cache, kde se kapacita SLC mění s obsazeností disků, které se někdy prostě zamyslí, jak přenáší data z SLC cache do normálního prostoru :-D
To se umějí dít věci :-D Když část probíhá, část timeoutuje, co to pak loguje...  :o ;D

ext4 je znacne rozsirenejsi tak je to bezpecna a solidna, a univerzalna, volba
No osobně bych se spíš bál třeba ZFS...ale třeba jsem jen srab...
« Poslední změna: 31. 08. 2024, 21:44:40 od CPU »

Re:Aky file system pre DB server?
« Odpověď #13 kdy: 31. 08. 2024, 22:05:10 »
přivést filesystémy skupiny EXT vysokou zátěží IOps (Bonnie++) do divného stavu

Rozdíl mezi serverovými a desktopovými disky je třeba v tom, že ten serverový se ve stanovené době přestane pokoušet o přečtení chybného sektoru. (Desktop se snaží data zachránit. Serverový spoléhá na paritu Raidu, tak to vzdá.)

Respekt k Vašim zkušenostem, a děkuji za tuto poznámku.

Ze své strany doplním, že jsem tento problém tehdy pozoroval v průběhu let na různých druzích disků a RAIDů. Ano používali jsme "desktopové" Barracudy, taky tehdejší Barracudy NS/ES, a sice vzácně, ale občas taky Cheetahy (U320 SCSI a později SAS). Sem tam nějaký Raptor/Velociraptor. A došel jsem k poměrně dobře podloženému závěru, že RAID a disky za to nemohly. Já jsem tu věc nakonec tuším pozoroval i na prostém HBA proti jedinému Cheetahu. A na iSCSI na 10Gb lince proti protějšímu boxu, který měl hodně RAM (a diskový subsystém se mu v tom stavu nezablokoval).

Stačilo restartovat hostitelský počítač, externí RAID na SCSI jel dál bez restartu, a problém zmizel (do další reprodukce).
Pokud jsem na tomtéž diskovém subsystému použil XFS nebo Reiser 3, jely testy klidně několik dní bez problému.

Když se Vám zamyslí disk, tak na RAIDu vidíte, že jednotlivému disku svítí kontrolka "activity". Podle toho se "jeden zpomalený disk" snadno pozná. Takové závady jsme samozřejmě taky vídali, a rutinně jsme je řešili výměnou disku.
Ten systematický problém, o kterém mluvím, vypadal jinak. Směrem na RAID a disky nic neteklo. Na ně se nečekalo. Prostě kernel z nějakého důvodu "čekal sám na sebe". Aniž by byl vytížený diskový subsystém nebo CPU, aniž by zamrzlo uživatelské rozhraní samo o sobě.

CPU

  • *****
  • 878
    • Zobrazit profil
    • E-mail
Re:Aky file system pre DB server?
« Odpověď #14 kdy: 31. 08. 2024, 23:01:32 »
Pokud jsem na tomtéž diskovém subsystému použil XFS nebo Reiser 3, jely testy klidně několik dní bez problému.

No, asi bych měl napsat něco jako "to není možné", ale spíš mi přijde odpovídající "ani mě to neudivuje".
Docela mě láká zkusit to vámi zmíněným Bonnie++ dostat EXT4 do stavu smrti.

BTW podobný problém:
https://forum.proxmox.com/threads/heavy-i-o-causes-kernel-panics-deadlocks-and-file-system-corruption-on-ext4.122008/

(A je vidět, že se ten člověk s diagnostikou docela nadřel!)

Ovšem nejvíc vtipné je rozuzlení...  :-\
Doplním, že jsem zkoušel vygooglovat nějaké informace o tom, jestli už to bylo opraveno, ale náhodou jsem vygoogloval něco, co jsem spíš popisoval já...  ;D

Mimochodem, je to záludné v tom, že takový disk by mohl s jiným FS nebo jiným rozdělením možná pořád dál fungovat :-D A to jednoduše proto, že se data jinak rozhází a chyba se přestane projevovat. Asi. Nesadil bych na to ani stovku :-D

Tím ovšem nepopírám vaše pozorování nebo nerozporuji vaše závěry.
Zreplikovat problém = možnost nechat to spravit...
Jen by to mělo chcípnout na kernelpanic...ne? ...když to nic nereportuje, hrozně blbě se to diagnostikuje, ale...mělo by to chcípnout na KP, když to nemůže logovat...
« Poslední změna: 31. 08. 2024, 23:06:35 od CPU »