Производителите на сървъри и доставчиците на облак предлагат различни видове решения за съхранение, за да се погрижат за нуждите на вашата база данни. Когато купуваме нов сървър или избираме облачен екземпляр за стартиране на нашата база данни, често се питаме – колко дисково пространство трябва да разпределим? Както ще разберем, отговорът не е тривиален, тъй като има редица аспекти, които трябва да се вземат предвид. Дисковото пространство е нещо, което трябва да се помисли предварително, защото свиването и разширяването на дисковото пространство може да бъде рискована операция за базирана на диск база данни.
В тази публикация в блога ще разгледаме как първоначално да оразмерим вашето пространство за съхранение и след това да планираме капацитет за поддържане на растежа на вашата MySQL или MariaDB база данни.
Как MySQL използва дисковото пространство
MySQL съхранява данни във файлове на твърдия диск в определена директория, която има системната променлива "datadir". Съдържанието на datadir ще зависи от версията на MySQL сървъра и заредените конфигурационни параметри и сървърни променливи (напр. general_log, slow_query_log, двоичен дневник).
Действителната информация за съхранение и извличане зависи от механизмите за съхранение. За механизма MyISAM индексите на таблицата се съхраняват във файла .MYI, в директорията с данни, заедно с .MYD и .frm файловете за таблицата. За машината InnoDB индексите се съхраняват в пространството за таблици, заедно с таблицата. Ако innodb_file_per_table е зададена опция, индексите ще бъдат в .ibd файла на таблицата заедно с .frm файла. За механизма на паметта данните се съхраняват в паметта (хийп), докато структурата се съхранява в .frm файла на диска. В предстоящия MySQL 8.0 файловете с метаданни (.frm, .par, dp.opt) се премахват с въвеждането на новата схема за речник на данни.
Важно е да се отбележи, че ако използвате споделено пространство за таблици InnoDB за съхраняване на таблични данни (innodb_file_per_table=OFF ), размерът на физическите ви данни в MySQL се очаква да нараства непрекъснато дори след като съкратите или изтриете огромни редове от данни. Единственият начин да възстановите свободното пространство в тази конфигурация е да експортирате, изтриете текущите бази данни и да ги импортирате обратно чрез mysqldump. Поради това е важно да зададете innodb_file_per_table=ON ако сте загрижени за дисковото пространство, така че когато съкращавате таблица, мястото може да бъде възстановено. Освен това с тази конфигурация огромна операция DELETE няма да освободи дисково пространство, освен ако OPTIMIZE TABLE не се изпълни след това.
MySQL съхранява всяка база данни в собствена директория под пътя "datadir". В допълнение, лог файловете и други свързани MySQL файлове като socket и PID файлове, по подразбиране, също ще бъдат създадени под datadir. От съображения за производителност и надеждност се препоръчва да съхранявате регистрационните файлове на MySQL на отделен диск или дял – особено MySQL регистрационните файлове за грешки и двоичните регистрационни файлове.
Оценка на размера на базата данни
Основният начин за оценка на размера е да се намери съотношението на растеж между две различни точки във времето и след това да се умножи с текущия размер на базата данни. Измерването на трафика на вашата база данни в пиковите часове за тази цел не е най-добрата практика и не представлява използването на вашата база данни като цяло. Помислете за пакетна операция или съхранена процедура, която се изпълнява в полунощ или веднъж седмично. Вашата база данни може да нарасне значително сутрин, преди евентуално да бъде свита от домакинска операция в полунощ.
Един възможен начин е да използваме нашите резервни копия като основен елемент за това измерване. Физическото архивиране като Percona Xtrabackup, MariaDB Backup и моментна снимка на файловата система ще доведе до по-точно представяне на размера на вашата база данни в сравнение с логическото архивиране, тъй като съдържа двоично копие на базата данни и индекси. Логическото архивиране като mysqldump съхранява само SQL изрази, които могат да бъдат изпълнени за възпроизвеждане на оригиналните дефиниции на обект на база данни и данни от таблица. Независимо от това, все още можете да излезете с добро съотношение на растеж, като сравните архивите на mysqldump.
Можем да използваме следната формула, за да оценим размера на базата данни:
Къде,
- Б - Пълен размер на резервното копие за текущата седмица,
- Б - Пълен размер на резервното копие от предишната седмица,
- Dbданни - Общ размер на данните на базата данни,
- Dbиндекс - Общ размер на индекса на базата данни,
- 52 - Брой седмици в годината,
- Д - Година.
Общият размер на базата данни (данни и индекси) в MB може да се изчисли с помощта на следните изрази:
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 |
+---------------+Горното уравнение може да бъде променено, ако вместо това искате да използвате месечните архиви. Променете постоянната стойност от 52 на 12 (12 месеца в годината) и сте готови.
Също така, не забравяйте да отчетете innodb_log_file_size x 2, innodb_data_file_path а за Galera Cluster добавете gcache.size стойност.
Оценка на размера на двоични регистрационни файлове
Двоичните регистрационни файлове се генерират от MySQL главната за целите на репликация и възстановяване в момента. Това е набор от лог файлове, които съдържат информация за модификации на данни, направени на MySQL сървъра. Размерът на двоичните регистрационни файлове зависи от броя на операциите на запис и от формата на двоичния регистрационен файл - STATEMENT, ROW или MIXED. Базираният на израз двоичен дневник обикновено е много по-малък в сравнение с базиран на ред двоичен дневник, тъй като се състои само от оператори за запис, докато базираният на редове се състои от информация за модифицирани редове.
Най-добрият начин да оцените максималното използване на диска за двоични регистрационни файлове е да измерите размера на двоичния дневник за един ден и да го умножите с expire_logs_days стойност (по подразбиране е 0 - няма автоматично премахване). Важно е да зададете expire_logs_days така че можете да прецените правилно размера. По подразбиране всеки двоичен регистрационен файл е ограничен около 1GB, преди MySQL да завърти двоичния регистрационен файл. Можем да използваме MySQL събитие, за да изчистим просто двоичния дневник за целите на тази оценка.
Първо, уверете се, че променливата event_scheduler е активирана:
mysql> SET GLOBAL event_scheduler = ON;След това, като привилегирован потребител (с привилегии EVENT и RELOAD), създайте следното събитие:
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;За работно натоварване с интензивно писане вероятно трябва да съкратите интервала до 30 минути или 10 минути, преди двоичният дневник да достигне максимален размер от 1 GB, след което да закръглите изхода до един час. След това проверете състоянието на събитието, като използвате следния израз и погледнете колоната LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...След това разгледайте двоичните регистрационни файлове, които имаме сега:
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 |
+---------------+------------+След това можем да изчислим средната стойност на растежа на нашите двоични регистрационни файлове, която е около ~562 MB на час през пиковите часове. Умножете тази стойност с 24 часа и expire_logs_days стойност:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Ще получим 94416 MB, което е около ~95 GB на дисково пространство за нашите двоични регистрационни файлове. Релейните регистрационни файлове на подчинения са по същество същите като двоичните регистрационни файлове на главния, с изключение на това, че се съхраняват от страната на подчинения. Следователно това изчисление се отнася и за регистрите на подчинено реле.
Шпинделен диск или твърдо състояние?
Има два типа I/O операции на MySQL файлове:
- Последователни I/O-ориентирани файлове:
- Пространство за таблици на системата InnoDB (ibdata)
- Регистрационни файлове на MySQL:
- Двоични регистрационни файлове (binlog.xxxx)
- РЕДО регистрационни файлове (ib_logfile*)
- Общи регистрационни файлове
- Бавни регистрационни файлове на заявките
- Регистър на грешките
- Произволни I/O-ориентирани файлове:
- файл с данни InnoDB файл на таблица (*.ibd) с innodb_file_per_table=ON (по подразбиране).
Помислете за поставяне на произволни I/O-ориентирани файлове в дискова подсистема с висока пропускателна способност за най-добра производителност. Това може да бъде флаш устройство - или SSD или NVRAM карта, или шпинделни дискове с високи обороти като SAS 15K или 10K, с хардуерен RAID контролер и акумулаторно устройство. За последователни I/O-ориентирани файлове, съхраняването на HDD с кеш за запис с батерии трябва да е достатъчно добро за MySQL. Имайте предвид, че е вероятно влошаване на производителността, ако батерията е изтощена.
Ще покрием тази област (оценка на пропускателната способност на диска и разпределението на файлове) в отделна публикация.
Планиране и оразмеряване на капацитета
Планирането на капацитет може да ни помогне да изградим сървър на производствена база данни с достатъчно ресурси, за да оцелеем при ежедневни операции. Трябва също да предвидим неочаквани нужди, да отчетем бъдещи нужди за съхранение и пропускателна способност на диска. По този начин планирането на капацитета е важно, за да се гарантира, че базата данни има достатъчно място за дишане до следващия цикъл на опресняване на хардуера.
Най-добре е да илюстрирате това с пример. Имайки предвид следния сценарий:
- Следващ хардуерен цикъл:3 години
- Текущ размер на базата данни:2013 MB
- Текущ пълен размер на резервното копие (седмица N):1177 MB
- Предишен размер на пълен архив (седмица N-1):936 MB
- Делта размер:241MB на седмица
- Делта съотношение:25,7% увеличение на седмица
- Общо седмици за 3 години:156 седмици
- Оценка на общия размер на базата данни:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB след 3 години
Ако използвате двоични регистрационни файлове, сумирайте го от стойността, която получихме в предишния раздел:
- 81 + 95 =176 GB място за съхранение за база данни и двоични регистрационни файлове.
Добавете поне 100% повече място за оперативни и поддържащи задачи (локално архивиране, стадиране на данни, регистър на грешки, файлове на операционната система и т.н.):
- 176 + 176 =352 GB общо дисково пространство.
Въз основа на тази оценка можем да заключим, че ще ни трябват поне 352 GB дисково пространство за нашата база данни за 3 години. Можете да използвате тази стойност, за да оправдаете вашата нова покупка на хардуер. Например, ако искате да закупите нов специален сървър, можете да изберете 6 x 128 SSD RAID 10 с RAID контролер с батерии, който ще ви даде около 384 GB общо дисково пространство. Или, ако предпочитате облак, можете да получите 100 GB блоково хранилище с осигурени IOPS за използване на нашата база данни от 81 GB и да използвате стандартното постоянно блоково хранилище за нашите 95 GB двоични регистрационни файлове и друго оперативно използване.
Приятно оразмеряване!
