Datábaze v ramdisku

[Santa]

Vo firme sme riesili potrebu zrychlit pristup k datam v databaze (MariaDB), kde sme narazili na bottle-neck pristupove doby a rychlosti citania diskov. Zvazovali sme najprv nasadenie SSD, no koli obave z ich nizsej zivotnosti padol vyber na RAMdisk.

Volba padla na brd modul. Uvodne testy ukazali, ze idem spravnym smerom:

Zapis:
------

Kód: [Vybrat]

santa@DB-server:~$ sudo dd if=/dev/zero of=/mnt/disk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 22.1489 s, 185 MB/s

santa@DB-server:~$ sudo dd if=/dev/zero of=/mnt/ramdisk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 6.75993 s, 606 MB/s

Citanie:

Kód: [Vybrat]

santa@DB-server:~$ sudo dd if=/mnt/disk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 20.8874 s, 196 MB/s


santa@DB-server:~$ sudo dd if=/mnt/ramdisk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 1.94548 s, 2.1 GB/s


Potreba rychleho citania dat a zaroven nutnost zabezpecit data proti vypadku ma doviedla ku kombinacii SW RAID 1 nad diskom a ramdiskom.

vytvoril som si prazdny image subor (52GB) a ten pripojil na loop5, a pre ramdisk som nastavil rovnaku velkost, 52GB. (server ma 64 GB RAM)

Nasledne som pomocou mdadm vytvoril RAID 1 zariadenie, formatol ho a pripojil.

Kód: [Vybrat]

mdadm -C /dev/md1 -n 2 -l 1 /dev/ram0 -W /dev/loop5
mkfs.ext4 /dev/md1
mount /dev/md1 /mnt/ramdisk

Vysledne casy boli viac ako uspokojive:

Kód: [Vybrat]

santa@DB-server:~# sudo dd if=/dev/zero of=/mnt/ramdisk/aa bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 15.3726 s, 266 MB/s


santa@DB-server:~# sudo dd if=/mnt/ramdisk/aa of=/dev/null bs=4k count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 1.79785 s, 2.3 GB/s

Zostala uz len posledna vec, ako zabezpecit, aby po restarte servera doslo k spusteniu RAIDu a rekonstrukcii obsahu RAMdisku a revalidacii takehoto pola:

Kód: [Vybrat]

/sbin/losetup /dev/loop5 /srv/db_images/ramdisk.img
mdadm --assemble /dev/md1 /dev/loop5
mdadm --run /dev/md1
mdadm --manage /dev/md1 --add /dev/ram0
mount /dev/md1 /mnt/ramdisk

nasledne som na diskovej urovni pri vypnutom MariaDB presunul databazy, ktore som potreboval zrychlit do /mnt/ramdisk/ a vytvortil z /var/lib/mysql linky na ramdisk.

That's all...
Snad toto niekomu pomoze, ked bude potrebovat nieco podobne riesit. komplexne selekty nad takto vytvorenou databazou lietaju ako namydlene

[Reklama]

[Petr Krčmář]

Tohle nepatří do fóra, ale spíš do blogu nebo rovnou do článku. Nechceš se ještě víc podrobně rozepsat a udělat z toho článek?

[Santa]

Povodne som to chcel dat do blogu ale pri registracii mi to pise ze z mojej lokality nie je mozne zalozit blog. Ako by som bol niekde na marse

PS: aj forum sa ma pyta na nejake veci ktore ako clovek zijuci mimo uzemia CR fakt musim googlit (druhe najvacsie mesto v Cesku je......Ve kterém měsíci proběhla sametová revoluce? ... (chvilku mi tvalo ze november je u vas listopad )

[JardaP .]

Jeste zbyva zabezpecit, aby nejaky vul nerestartoval stroj, kdyz je zrovna rozpadly RAID.

[ZAJDAN]

no tak to je tedy velmi slušná akce! tohdle by stálo opravdu na pěkně napsaný článek

[Reklama]

[Ivan]

Nechapu. Proc to pamet dostal RAM disk? Nebylo by lepsi mit velkou buffer-cache?

[Astar]

Hmm, neriesi 99% tvojich problemov memory table?

[OMG]

co se stane az to padne? data na hdd nebudou v sync s RAM, tudiz budes mit 1 poskozeny zdroj dat a 1 zadny zdroj dat. Nebo se pletu?

[Kolemjdoucí]

Nechci Vám kazit radost, ale každý normální DB stroj na zeměkouli umí využít velkou RAM pro selecty automaticky, respektive když se mu povolí příslušné velké množství paměti používat. Nepřekvapivě to MariaDB umí také, ovšem musí se to nastavit ručně.

[trubicoid2]

lepsi by bylo udelat raid1 pres dva ruzny disky s write-mostly a jeden ramdisk; pak by nevadilo zdechnuti jednoho disku

nebo jeste pro sichr udelat pred restartem pocitace nebo periodicky cronem kopii ramdisku uplne nekam jinam, na to skripty jsou, treba namatkou http://www.observium.org/wiki/Persistent_RAM_disk_RRD_storage

tedy by ramdisk sel obnovit pri restartu pred rebuildem a nespolehalo by se jen na data na disku

[Santa]

Pokusim sa zhrnut odpovede do jedneho prispevku:

JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.

Ivan,Kolemjdoucí: ramdisk koli tomu, ze potrebujem aby len niektore schemy (databazy) boli priorizovane na citanie. buffering, ci globalne settingy su fajna vec, to boli uvodne optimalizacie. Nevies to vsak nastavit per table, ale len per engine. a ked mas tak ako my, auditovanu databazu (ked nastane update na zazname, automaticky do tzv. historickej tabulky sa pridava povodny zasnam - before update trigger) tak ramkou plytvas na X nepodstatnych veci, lebo DB engine nerozlisuje prioritu tabuliek, schem.

Astar: memory_table neriesi podstatny problem, perzistencia ukladanych dat. ak ti masina klakne, data z memory_table su ta-tam...

[Santa]

trubicoid2: mas pravdu, preto som nasledne este z NAS cez iSCSI pripojil remote volume ako dalsi disk do tohoto raisu, takze vo vysledku mas data v ramdisku, na lokalnom disku a nasledne este na geograficky oddelenom NASku (druha serverovna)

[OMG]

Pokusim sa zhrnut odpovede do jedneho prispevku:
JardaP, OMG: kludne moze aj v tejto faze vypadnut masina, nakolko dochadza k rekonstrukcii RAM oddielu, ktory je tak ci tak prazdny pri boote. Preto sa /dev/rd1 inicializuje manualne tak, ze sa prida najprv disk, a nasledne ked rd1 bezi, prida sa ram oddiel, ktory sa automaticky naplni datami.

zkusim se zeptat jeste jednou - mas stroj s raid1 (1disk, 1ram) do toho raid 1 jsi nakopiroval nejakou databazi. Pokud je ta databaze jenom pro cteni, zadny problem. Pokud ale udelas nejaky insert, tak ty data je potrebne zapsat do toho raid a tudiz i na disk ktery je v tom raid. Ted si predstav ze delas nekolik insertu a cast dat se jiz zapisuje na disk a dojde k resetu stroje... Tudiz to raid1 pole je z meho pohledu nefunkcni, v ram nic neni, na disku je neco zapsano neco ne...
Z toho co jsi napsal mi vychazi:
1. databaze je jenom pro cteni, tudiz je uplne jedno jestli stroj vypadne nebo ne, po startu se udela raid a nakopiruje se odnekud puvodni databaze
2. databaze neni pro cteni a tudiz pripadny vypadek nemas promysleny

[Santa]

OMG:

Databaza nie je len pre citanie. Zapis prebieha a v primare sa vykonava na disk, kedze ten je v poli oznaceny ako writemostly. Problem so stabilitou sa uplne vyriesi pridanim dalsieho disku, tak ako to naznacil trubicoid2.

btw: ak by v raid1 bol len jeden disk, a jede ramdisk, mohlo by dojst k tomu, ze su po tvrdom pade poskodene subory v /dev/loop5, v tom mas pravdu. preto som pridal dalsi disk, a teda RAID1 je nad 3 zariadeniami. primarne teda pri update table dochadza k zapisu na disky. preto je citanie rychle a zapis pomaly.... otestoval som to niekolkymi tvrdymi restartami masiny, odpojenim od siete (nedostupnost NAS) a funguje to. nevravim, ze neexistuje nejaky scenar, pri ktorom by tato zostava nedokazala havarovat, otazka je, za tie peniaze sa da postavit lepsie riesenie?

[OMG]

za tie peniaze sa da postavit lepsie riesenie?

nevidel jsem nikde kolik penez na to mas... resit performance databaze je na dlouhou diskusi, z koule to proste nikdo tady neumi...
reseni raid1 (disk+ram), pripadne (disk+ram+nas) je z principu pruserove i kdyz tve testy ukazuji ze ne.