Už to tady pár lidí naťuklo, ale nikdo to asi neřekl dostatečně přesvědčivě. Takže pozor:
Vykašli se na ten ramdisk!
Já taky před pár lety podobnou kravinu udělal, protože jsem nerozumněl tomu, jak MySQL funguje. Dnes se tomu směju.
Trocha teorie: MySQL (MariaDB), resp. InnoDB (o MyISAM/Aria 1.x se snad ani nebavíme) všechny operace provádí nad strukturou nazvanou buffer_pool umístěnou v RAM. Disk z pohledu běžícího innodb funguje spíš jako swap v OS kam se hází data až když se nevejdou do paměti (resp. non-dirty data se samozřejmě neukládají, protože tam už jsou, je to analogie trochu volná).
To znamená:
Tu velikost, kterou jsi nastavil ramdisku nastav na buffer_pool v konfiguráku MariaDB, díky tomu budeš mít všechna data v paměti a při čtení se o disk ani neškrne, navíc předejdeš zbytečnému kopírování RAMDisk -> buffer_pool.
Teď zápisy: MariaDB už nemá ten deb... ehm zbytečný limit 4GB na velikost logů. Máš-li místo na disku, nastav velké logy co to jde (typicky bývají ve 2 souborech a nastavuješ velikost jednoho souboru). Tím dosáhnež toho, že každý zápis se provede pouze v RAM + sekvenční zápis do logů (místo okamžitého random zápisu do disku ve tvém RAID1) a jednou za čas (pokud budeš mít velké logy, tak to budou klidně hodiny třebas i den) se část buffer_poolu zapíše na disk (navíc innodb to dělá docela inteligentně). Pokud ti ta rychlost bude ještě pořád málo, dej si logy na jiný disk.
Suma sumárum dostaneš takto vždy lepší výkon než nejlepší možný případ toho RAIDu s ramdiskem + plotna. Data budou vždy konzistentní (vše je v logách), jediný "problém" se kterým musíš počítat je, že pokud to spadne, bude chvíli (pár minut) trvat, než se přehrají logy (to můžeš sledovat v error logu). Ale toto je mnohokrát ověřený scénář, který funguje a na který se můžeš spolehnout. Ehm až teda na pád při běžícím alter table, truncate table atd., ale to je prostě průšvih návrhu MySQL, kterému se prostě nijak nevyhneš ani svým řešením (a zas tak často se to nestává).