Výrobci serverů a poskytovatelé cloudu nabízejí různé druhy řešení úložiště, která uspokojí vaše databázové potřeby. Při nákupu nového serveru nebo výběru cloudové instance pro provoz naší databáze se často ptáme sami sebe – kolik místa na disku bychom měli přidělit? Jak zjistíme, odpověď není triviální, protože je třeba zvážit řadu aspektů. Místo na disku je něco, na co je třeba myslet předem, protože zmenšování a rozšiřování místa na disku může být pro diskovou databázi riskantní operace.
V tomto příspěvku na blogu se podíváme na to, jak zpočátku velikost vašeho úložného prostoru a poté naplánovat kapacitu pro podporu růstu vaší databáze MySQL nebo MariaDB.
Jak MySQL využívá místo na disku
MySQL ukládá data do souborů na pevném disku pod konkrétním adresářem, který má systémovou proměnnou "datadir". Obsah datadir bude záviset na verzi serveru MySQL a načtených konfiguračních parametrech a proměnných serveru (např. general_log, slow_query_log, binární protokol).
Skutečné informace o ukládání a načítání závisí na úložných strojích. Pro stroj MyISAM jsou indexy tabulky uloženy v souboru .MYI v datovém adresáři spolu se soubory .MYD a .frm pro tabulku. U enginu InnoDB jsou indexy uloženy v tabulkovém prostoru spolu s tabulkou. Pokud innodb_file_per_table je nastavena, indexy budou v souboru .ibd tabulky spolu se souborem .frm. U paměťového jádra jsou data uložena v paměti (hromadě), zatímco struktura je uložena v souboru .frm na disku. V připravované verzi MySQL 8.0 jsou soubory metadat (.frm, .par, dp.opt) odstraněny se zavedením nového schématu datového slovníku.
Je důležité si uvědomit, že pokud používáte sdílený tabulkový prostor InnoDB pro ukládání dat tabulky (innodb_file_per_table=OFF ), očekává se, že velikost vašich fyzických dat MySQL bude neustále narůstat, i když zkrátíte nebo smažete velké řádky dat. Jediný způsob, jak získat zpět volné místo v této konfiguraci, je exportovat, smazat aktuální databáze a znovu je importovat zpět přes mysqldump. Proto je důležité nastavit innodb_file_per_table=ON pokud se obáváte o místo na disku, tak při zkrácení tabulky lze místo získat zpět. S touto konfigurací také velká operace DELETE neuvolní místo na disku, pokud nebude následně provedena OPTIMIZE TABLE.
MySQL ukládá každou databázi do vlastního adresáře pod cestou "datadir". Kromě toho budou soubory protokolu a další související soubory MySQL, jako jsou soubory socket a PID, ve výchozím nastavení také vytvořeny pod datadir. Z důvodu výkonu a spolehlivosti se doporučuje ukládat soubory protokolu MySQL na samostatný disk nebo oddíl – zejména protokol chyb MySQL a binární protokoly.
Odhad velikosti databáze
Základním způsobem odhadu velikosti je najít poměr růstu mezi dvěma různými body v čase a poté jej vynásobit aktuální velikostí databáze. Měření databázového provozu ve špičce pro tento účel není nejlepším postupem a nepředstavuje využití databáze jako celku. Přemýšlejte o dávkové operaci nebo uložené proceduře, která se spouští o půlnoci nebo jednou týdně. Vaše databáze by se mohla ráno potenciálně výrazně zvětšit, než by mohla být o půlnoci zmenšena úklidovou operací.
Jedním z možných způsobů je použít naše zálohy jako základní prvek pro toto měření. Fyzické zálohování, jako je Percona Xtrabackup, MariaDB Backup a snímek systému souborů, by poskytlo přesnější vyjádření velikosti vaší databáze ve srovnání s logickým zálohováním, protože obsahuje binární kopii databáze a indexy. Logická záloha, jako je mysqldump, ukládá pouze příkazy SQL, které lze provést k reprodukci původních definic databázových objektů a dat tabulek. Přesto stále můžete dosáhnout dobrého poměru růstu porovnáním záloh mysqldump.
Pro odhad velikosti databáze můžeme použít následující vzorec:
Kde,
- B – Úplná velikost zálohy aktuálního týdne,
- B – Úplná velikost zálohy za předchozí týden,
- Dbdata - Celková velikost dat databáze,
- Dbindex - Celková velikost indexu databáze,
- 52 - Počet týdnů v roce,
- Ano - Rok.
Celkovou velikost databáze (data a indexy) v MB lze vypočítat pomocí následujících příkazů:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+Výše uvedenou rovnici lze upravit, pokud chcete místo toho používat měsíční zálohy. Změňte konstantní hodnotu 52 na 12 (12 měsíců v roce) a můžete začít.
Také nezapomeňte započítat innodb_log_file_size x 2, innodb_data_file_path a pro Galera Cluster přidejte gcache.size hodnotu.
Odhad velikosti binárních protokolů
Binární protokoly generuje hlavní server MySQL pro účely replikace a obnovy v určitém okamžiku. Jedná se o sadu souborů protokolu, které obsahují informace o úpravách dat provedených na serveru MySQL. Velikost binárních protokolů závisí na počtu operací zápisu a formátu binárního protokolu – STATEMENT, ROW nebo MIXED. Binární protokol založený na příkazech je obvykle mnohem menší ve srovnání s binárním protokolem založeným na řádcích, protože sestává pouze z příkazů zápisu, zatímco řádkový sestává z upravených informací o řádcích.
Nejlepším způsobem, jak odhadnout maximální využití disku binárními protokoly, je změřit velikost binárního protokolu za den a vynásobit ji hodnotou expire_logs_days hodnota (výchozí je 0 - žádné automatické odstranění). Je důležité nastavit expire_logs_days abyste mohli správně odhadnout velikost. Ve výchozím nastavení je každý binární protokol omezen na přibližně 1 GB, než MySQL otočí soubor binárního protokolu. Můžeme použít událost MySQL k jednoduchému vyprázdnění binárního protokolu pro účely tohoto odhadu.
Nejprve se ujistěte, že je povolena proměnná event_scheduler:
mysql> SET GLOBAL event_scheduler = ON;Poté jako privilegovaný uživatel (s oprávněními EVENT a RELOAD) vytvořte následující událost:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Při zátěži náročné na zápis budete pravděpodobně muset zkrátit interval na 30 minut nebo 10 minut, než binární protokol dosáhne maximální velikosti 1 GB, a poté zaokrouhlit výstup na hodinu. Poté ověřte stav události pomocí následujícího příkazu a podívejte se na sloupec LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Pak se podívejte na binární protokoly, které nyní máme:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Poté můžeme vypočítat průměr růstu našich binárních protokolů, který je kolem ~562 MB za hodinu ve špičce. Vynásobte tuto hodnotu 24 hodinami a expire_logs_days hodnota:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Dostaneme 94416 MB, což je přibližně ~95 GB místa na disku pro naše binární protokoly. Protokoly relé Slave jsou v podstatě stejné jako binární protokoly mastera, až na to, že jsou uloženy na straně Slave. Proto tento výpočet platí také pro protokoly podřízeného relé.
Spindle Disk nebo Solid State?
Existují dva typy I/O operací se soubory MySQL:
- Sekvenční I/O-orientované soubory:
- Tabulkový prostor systému InnoDB (ibdata)
- Soubory protokolu MySQL:
- Binární protokoly (binlog.xxxx)
- REDO protokoly (ib_logfile*)
- Obecné protokoly
- Pomalé protokoly dotazů
- Protokol chyb
- Náhodné I/O-orientované soubory:
- Datový soubor InnoDB file-per-table (*.ibd) s nastavením innodb_file_per_table=ON (výchozí).
Zvažte umístění náhodných I/O souborů do vysoce výkonného diskového subsystému pro nejlepší výkon. Může to být flash disk – buď SSD nebo karta NVRAM, nebo vřetenové disky s vysokými otáčkami jako SAS 15K nebo 10K, s hardwarovým řadičem RAID a baterií zálohovanou jednotkou. Pro sekvenční I/O soubory by mělo být pro MySQL dostačující ukládání na HDD s baterií zálohovanou mezipamětí pro zápis. Pamatujte, že pokud je baterie vybitá, pravděpodobně dojde ke snížení výkonu.
Této oblasti (odhadu propustnosti disku a alokaci souborů) se budeme věnovat v samostatném příspěvku.
Plánování kapacit a dimenzování
Kapacitní plánování nám může pomoci vybudovat produkční databázový server s dostatkem zdrojů pro přežití každodenních operací. Musíme také zajistit neočekávané potřeby, počítat s budoucími potřebami úložiště a propustnosti disku. Plánování kapacity je tedy důležité, aby bylo zajištěno, že databáze bude mít dostatek prostoru na dýchání až do příštího cyklu obnovy hardwaru.
Nejlepší je to ilustrovat na příkladu. S ohledem na následující scénář:
- Další hardwarový cyklus:3 roky
- Aktuální velikost databáze:2013 MB
- Aktuální velikost plné zálohy (týden N):1177 MB
- Velikost předchozí plné zálohy (týden N-1):936 MB
- Velikost delta:241 MB za týden
- Poměr delta:25,7% přírůstek za týden
- Celkový počet týdnů za 3 roky:156 týdnů
- Odhad celkové velikosti databáze:((1177–936) x 2013 x 156)/936 =80856 MB ~ 81 GB po 3 letech
Pokud používáte binární protokoly, sečtěte to z hodnoty, kterou jsme získali v předchozí části:
- 81 + 95 =176 GB úložného prostoru pro databáze a binární protokoly.
Přidejte alespoň o 100 % více prostoru pro provozní a údržbové úlohy (místní zálohování, příprava dat, protokol chyb, soubory operačního systému atd.):
- 176 + 176 =352 GB celkového místa na disku.
Na základě tohoto odhadu můžeme usoudit, že bychom pro naši databázi na 3 roky potřebovali minimálně 352 GB diskového prostoru. Tuto hodnotu můžete použít k ospravedlnění nákupu nového hardwaru. Pokud si například chcete koupit nový dedikovaný server, můžete se rozhodnout pro 6 x 128 SSD RAID 10 s řadičem RAID zálohovaným baterií, který vám poskytne přibližně 384 GB celkového místa na disku. Nebo, pokud dáváte přednost cloudu, můžete získat 100 GB blokového úložiště se zřízeným IOPS pro využití naší 81GB databáze a použít standardní trvalé blokové úložiště pro naše 95GB binární protokoly a další provozní využití.
Šťastné dimenzování!