MariaDB/MySQL partitioning a diskové oddíly

[Aleš Rygl]

Zravím,

sháním nějaký tip nebo radu ohledně partitioningu v MariaDB vs. diskové oddíly na na serveru. Mám DB s jednoduchými shodnými tabulkami, do které denně přibude cca 20 milionu řádků. Za den je to podle použitého engine cca 43GiB (InnoDB), 17 GiB (InnoDB compressed), 18.5GiB (Aria) dat. Během práce DB vzniká cca 30 GiB dat binárních logů za hodinu - masivně se updatuje a insertuje jedna z tabulek.
Na serveru HP DL380 G9 mam 4x 400GB SSD a 4x 900GB HDD na P440 Smart Array, server ma 256GB RAM. Hledám optimální způsob využití diskového prostoru. Zatím mam range partitioning po dnech spolu se subpartitions podle key. To samo o sobě funguje dobře. Stačí každý den vytvořit novou partition a dropnout staré. Momentálně jsou SSD disky v RAID 1+0, což dělá cca 716 GiB místa pro data a logy databáze. HDD mám také RAID1+0.
Potřeboval bych nějak využít volný prostor na SSD a HDD tak, aby ideálně partitions se starými daty byly na HDD a nově vznikajicí na SSD. Při definici partitions se dá říct, kde data fyzicky budou, ale změnit to po naplnění partition jde jen za cenu přesunu dat a to trvá i hodinu. MySQL umí v posledních verzích general tablespaces, ale přesun dat mezi nimi je jak se zdá také za cenu rebuildu partition. Což dost nasazení partitioningu v mém případě dost omezuje.
Zatím nejnadějnější se mi jeví nasadit lvmcache. Část SSD kapacity použil jako tu cache pro HDD RAID a zbytek pro binární logy DB. Ale je to tak trochu skoda tech SSD. Ve finále by DB měly být dvě a měla by mezi nimi běžet Master-Slave replikace.

Nečekám řešení, potřeboval bych spíš nasměrovat, pokud někdo zkušenější něco podobného řešil.
A.

[Reklama]

[Ivan Nový]

Zravím,

sháním nějaký tip nebo radu ohledně partitioningu v MariaDB vs. diskové oddíly na na serveru. Mám DB s jednoduchými shodnými tabulkami, do které denně přibude cca 20 milionu řádků. Za den je to podle použitého engine cca 43GiB (InnoDB), 17 GiB (InnoDB compressed), 18.5GiB (Aria) dat. Během práce DB vzniká cca 30 GiB dat binárních logů za hodinu - masivně se updatuje a insertuje jedna z tabulek.
Na serveru HP DL380 G9 mam 4x 400GB SSD a 4x 900GB HDD na P440 Smart Array, server ma 256GB RAM. Hledám optimální způsob využití diskového prostoru. Zatím mam range partitioning po dnech spolu se subpartitions podle key. To samo o sobě funguje dobře. Stačí každý den vytvořit novou partition a dropnout staré. Momentálně jsou SSD disky v RAID 1+0, což dělá cca 716 GiB místa pro data a logy databáze. HDD mám také RAID1+0.
Potřeboval bych nějak využít volný prostor na SSD a HDD tak, aby ideálně partitions se starými daty byly na HDD a nově vznikajicí na SSD. Při definici partitions se dá říct, kde data fyzicky budou, ale změnit to po naplnění partition jde jen za cenu přesunu dat a to trvá i hodinu. MySQL umí v posledních verzích general tablespaces, ale přesun dat mezi nimi je jak se zdá také za cenu rebuildu partition. Což dost nasazení partitioningu v mém případě dost omezuje.
Zatím nejnadějnější se mi jeví nasadit lvmcache. Část SSD kapacity použil jako tu cache pro HDD RAID a zbytek pro binární logy DB. Ale je to tak trochu skoda tech SSD. Ve finále by DB měly být dvě a měla by mezi nimi běžet Master-Slave replikace.

Nečekám řešení, potřeboval bych spíš nasměrovat, pokud někdo zkušenější něco podobného řešil.
A.

Co tahle to rozdělit na dva servery a využít replikaci. Viz http://dev.mysql.com/doc/refman/5.7/en/replication.html a zde https://dev.mysql.com/doc/mysql-backup-excerpt/5.1/en/replication-solutions-backups.html

[MP]

No muj nazor je, ze pokud chcete jednorazove presunout velky balik dat z SSD na HDD, tak Vam zadna cache nakonec nepomuze, ten presun bude trvat porad stejne dlouho, brzdou jsou IOPS tech HDD. A to uz tam mate cache na P440.

[Ivan Nový]

No muj nazor je, ze pokud chcete jednorazove presunout velky balik dat z SSD na HDD, tak Vam zadna cache nakonec nepomuze, ten presun bude trvat porad stejne dlouho, brzdou jsou IOPS tech HDD. A to uz tam mate cache na P440.

A právě replikace to udělá postupně a bude přenášet jen rozdíly.

[Ivan Nový]

No muj nazor je, ze pokud chcete jednorazove presunout velky balik dat z SSD na HDD, tak Vam zadna cache nakonec nepomuze, ten presun bude trvat porad stejne dlouho, brzdou jsou IOPS tech HDD. A to uz tam mate cache na P440.

Další možnost je použít rsync. Viz zde http://mah.everybody.org/docs/mysql-rsync

[Reklama]

[Aleš Rygl]

Nevim, jestli si uplne rozumime. Hodilo by se mi neco, co nejak spoji obe pole  do jednoho tak, jako to delaji enterprise class uloziste pod oznacenim "Automated tiered storage". Horka data se pak udrzuji na SSD, ostatni na HDD. Presun velkeho baliku dat mezi poli v ramci serveru neni tak zle, sekvencni cleni a zapis (HDD) je kolem  400MB/s. Problem je, ze pokud to dela databaze (neni to obycejne kopirovani), je to problem, krom pomalosti se cela partitionovana tabulka zamkne.

[Ivan Nový]

Nevim, jestli si uplne rozumime. Hodilo by se mi neco, co nejak spoji obe pole  do jednoho tak, jako to delaji enterprise class uloziste pod oznacenim "Automated tiered storage". Horka data se pak udrzuji na SSD, ostatni na HDD. Presun velkeho baliku dat mezi poli v ramci serveru neni tak zle, sekvencni cleni a zapis (HDD) je kolem  400MB/s. Problem je, ze pokud to dela databaze (neni to obycejne kopirovani), je to problem, krom pomalosti se cela partitionovana tabulka zamkne.

Asi bych se snažil využí toho co MySql nabízí a MySQL nabízí tento scénář, viz zde i se schématem http://dev.mysql.com/doc/refman/5.7/en/replication-solutions-scaleout.html

[Ivan Nový]

Ještě jsem našel toto http://www.fromdual.ch/sites/default/files/application_partitioning_wp.pdf

[asd]

Takze hledas spise reseni pro tiered storage...

Existovalo neco jako LVMTS, ale to nevim jestli stale zije, nebo tu umrelo, popripade muzes zkusit tohle: http://www.lessfs.com/wordpress/?p=938

[Aleš Rygl]

Diky vsem za tipy. Prostuduji. O btier/lessfs jsem cetl, ale prijde mi, ze to umrelo.

[Tom K]

Mas to na fyzickem zeleze nebo na nejake virtualizaci? VMware i Hyper-V umi tiered storage nativne.
Vyhodou pak je, ze presun dat HDD/SSD si ridi hypervisor a nejake zamykani tabulek pri presunu nehrozi.
Nevyhodou pak to, ze ani OS ani MariaDB nevi, ze pracuji s tiered storage a nemuzou sve zapisy nijak optimalizovat, coz by teoreticky mohly lepe nez hypervisor (ktery zas nevi co se vlastne zapisuje).

[Aleš Rygl]

Mas to na fyzickem zeleze nebo na nejake virtualizaci? VMware i Hyper-V umi tiered storage nativne.
Vyhodou pak je, ze presun dat HDD/SSD si ridi hypervisor a nejake zamykani tabulek pri presunu nehrozi.
Nevyhodou pak to, ze ani OS ani MariaDB nevi, ze pracuji s tiered storage a nemuzou sve zapisy nijak optimalizovat, coz by teoreticky mohly lepe nez hypervisor (ktery zas nevi co se vlastne zapisuje).

Je to fyzicke zelezo. O nativni podpore tiered storage v VMware a Hyper-V jsem nevedel, to je docela zajimave, Diky. Momentalne testuju variantu s tou SSD cache (lvmcache) a tedy nic moc. Schvalne jsem to udelal tak ze mam 200GB SSG cache a 2TB RAID5 na HDD. Read hit ratio je kolem 40% a write jen asi 6% a oboji stale klesa. Asi je to tim mym specifickym druhem zateze.