Оптимизация на MySQL Storage Engine:Конфигуриране на InnoDB оптимизация за висока производителност

InnoDB е една от най-широко използваните машини за съхранение в MySQL. Този двигател за съхранение е известен като високонадежден и високопроизводителен двигател за съхранение и неговите ключови предимства включват поддръжка на заключване на ниво ред, външни ключове и следване на модела ACID. InnoDB заменя MyISAM като машина за съхранение по подразбиране от MySQL 5.5, която беше пусната през 2010 г.

Този механизъм за съхранение може да бъде невероятно производителен и мощен, ако е оптимизиран правилно - днес разглеждаме нещата, които можем да направим, за да работим възможно най-добре, но преди да се потопим в InnoDB обаче, трябва да разберем какво представлява гореспоменатият ACID модел.

Какво е ACID и защо е важно?

ACID е набор от свойства на транзакциите в базата данни. Акронимът се превежда на четири думи:атомарност, последователност, изолация и издръжливост. Накратко, тези свойства гарантират, че транзакциите в базата данни се обработват надеждно и гарантират валидност на данните въпреки грешки, прекъсвания на захранването или всякакви подобни проблеми. За система за управление на база данни, която се придържа към тези принципи, се казва, че е ACID-съвместима СУБД. Ето как работи всичко в InnoDB:

Атомарността гарантира, че изявленията в транзакцията работят като неделима единица и че ефектите от тях се виждат колективно или изобщо не се виждат;
Съгласуваността се обработва от механизмите за регистриране на MySQL, които записват всички промени в базата данни;
Изолацията се отнася до заключването на ниво ред на InnoDB;
Издръжливостта също се поддържа, защото InnoDB поддържа регистрационен файл, който проследява всички промени в системата.

Разбиране на InnoDB

Сега, когато разгледахме ACID, вероятно трябва да погледнем как изглежда InnoDB под капака. Ето как изглежда InnoDB отвътре (изображението е предоставено с любезното съдействие на Percona):

InnoDB Internals

От изображението по-горе можем ясно да видим, че InnoDB има няколко параметри, които са от решаващо значение за неговата производителност, а те са както следва:

Параметърът innodb_data_file_path описва системното пространство за таблици (системното пространство за таблици е зоната за съхранение на речника за данни InnoDB, двойните буфери за запис и промяна и регистрационни файлове за отмяна). Параметърът изобразява файла, в който ще се съхраняват данните, получени от InnoDB таблици;
Параметърът innodb_buffer_pool_size е буфер на паметта, който InnoDB използва за кеширане на данни и индекси на своите таблици;
Параметърът innodb_log_file_size изобразява размера на регистрационните файлове на InnoDB;
Параметърът innodb_log_buffer_size се използва за запис в регистрационните файлове на диска;
Параметърът innodb_flush_log_at_trx_commit контролира баланса между стриктно съответствие с ACID и по-висока производителност;
Параметърът innodb_lock_wait_timeout е продължителността от време в секунди, през която транзакцията InnoDB изчаква заключване на ред, преди да се откаже;
Параметърът innodb_flush_method дефинира метода, използван за прехвърляне на данни към InnoDB файлове с данни и регистрационни файлове, които могат да повлияят на I/O пропускателната способност.

InnoDB също така съхранява данните от своите таблици във файл, наречен ibdata1 - регистрационните файлове обаче се съхраняват в два отделни файла с име ib_logfile0 и ib_logfile1:всички тези три файла се намират в /var/lib/mysql директория.

За да направим InnoDB възможно най-ефективна, трябва да прецизираме тези параметри и да ги оптимизираме колкото е възможно повече, като разгледаме наличните ни хардуерни ресурси.

Настройка на InnoDB за висока производителност

За да коригирате производителността на InnoDB на вашия хардуер, следвайте тези стъпки:

За да разширите innodb_data_file_path автоматично, посочете атрибута autoextend в настройката и рестартирайте сървъра. Например:

innodb_data_file_path=ibdata1:10M:autoextend

Когато се използва параметърът autoextend, файлът с данни автоматично се увеличава с нараствания от 8MB всеки път, когато е необходимо пространство. Нов файл с данни за автоматично разширяване също може да бъде определен по този начин (в този случай новият файл с данни се нарича ibdata2):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

Когато използвате InnoDB, основният използван механизъм е буферният пул. InnoDB силно разчита на буферния пул и като правило параметърът innodb_buffer_pool_size трябва да бъде около 60% до 80% от общата налична RAM памет на сървъра. Имайте предвид, че трябва да оставите малко RAM и за процесите, изпълнявани в операционната система;
Размерът innodb_log_file_size на InnoDB трябва да бъде зададен възможно най-голям, но не по-голям от необходимото. В този случай имайте предвид, че по-голям размер на регистрационния файл е по-добър за производителност, но колкото по-голям е, толкова повече време за възстановяване след срив е необходимо. Като такова няма решение „един размер за всички“, но се казва, че комбинираният размер на регистрационните файлове трябва да бъде достатъчно голям. Това помага на MySQL сървъра да работи редовно по контролни точки и активност за прочистване на диска. Това спестява твърде много CPU и дисково IO и може да работи безпроблемно по време на пиковото си време или при висока активност на работното натоварване. Въпреки че препоръчителният подход е да го тествате и експериментирате сами и сами да намерите оптималната стойност;
Стойността innodb_log_buffer_size трябва да е най-малко 16M. Големият буфер на регистрационните файлове позволява да се изпълняват големи транзакции, без да е необходимо записване на дневника на диск, преди транзакциите да запазят част от дисковия вход/изход;
Когато настройвате innodb_flush_log_at_trx_commit, имайте предвид, че този параметър приема три стойности - 0, 1 и 2. Със стойност 1 получавате съответствие с ACID и със стойности 0 или 2 получавате по-висока производителност, но по-малко надеждност, защото в този случай транзакции, за които регистрационните файлове все още не са изхвърлени на диска, могат да бъдат загубени при срив;
За да зададете innodb_lock_wait_timeout на правилна стойност, имайте предвид, че този параметър дефинира времето в секунди (стойността по подразбиране е 50) преди издаване на следната грешка и връщане назад на текущия оператор:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

В InnoDB има множество налични методи за изчистване. По подразбиране тази настройка е зададена на “async_unbuffered” на Windows машини, ако стойността е зададена на NULL и на “fsync” в Linux машини. Ето какви са методите и какво правят:

InnoDB Flush Method	Цел
нормално	InnoDB ще използва симулиран асинхронен I/O и буфериран I/O.
небуфериран	InnoDB ще използва симулиран асинхронен I/O и небуфериран I/O.
async_unbuffered	InnoDB ще използва Windows асинхронен I/O и небуфериран I/O. Настройки по подразбиране на машини с Windows.
fsync	InnoDB ще използва функцията fsync() за изтриване на данните и регистрационните файлове. Настройка по подразбиране на машини с Linux.
O_DSYNC	InnoDB ще използва O_SYNC за отваряне и изтриване на регистрационните файлове и функцията fsync() за изтриване на файловете с данни. O_DSYNC е по-бърз от O_DIRECT, но данните може или не могат да бъдат последователни поради забавяне или пълен срив.
nosync	Използва се за вътрешно тестване на производителността – не се поддържа.
littlesync	Използва се за вътрешно тестване на производителността – не се поддържа.
O_DIRECT	InnoDB ще използва O_DIRECT за отваряне на файловете с данни и функцията fsync() за изтриване както на данните, така и на регистрационните файлове. В сравнение с O_DSYNC, O_DIRECT е по-стабилен и по-последователен на данните, но по-бавен. Кешът на операционната система ще се избягва с помощта на тази настройка - тази настройка е препоръчителната настройка на машини с Linux.
O_DIRECT_NO_FSYNC	InnoDB ще използва O_DIRECT по време на изтриване на I/O - частта „NO_FSYNC“ дефинира, че функцията fsync() ще бъде пропусната.

Трябва също да помислите за активиране на настройката innodb_file_per_table. Този параметър е ВКЛЮЧЕН по подразбиране в MySQL 5.6 и по-нови версии. Този параметър ви освобождава от проблеми с управлението, свързани с InnoDB таблици, като ги съхранява в отделни файлове и избягва раздути основни речници и системни таблици. Активирането на тази променлива също така избягва изправянето пред сложност при възстановяване на данни, когато определена таблица е повредена
Сега, след като променихте тези настройки съгласно инструкциите, описани по-горе, би трябвало да сте почти готови да тръгнете! Преди да започнете работа обаче, вероятно трябва да следите най-натоварения файл в цялата инфраструктура на InnoDB – ibdata1.

Работа с ibdata1

Има няколко класа информация, които се съхраняват в ibdata1:

Данните от таблици InnoDB;
Индексите на InnoDB таблици;
Метаданни на таблицата InnoDB;
Данни за управление на едновременното управление на много версии (MVCC);
Буферът за двойно записване – такъв буфер позволява на InnoDB да се възстанови от наполовина написани страници. Целта на такъв буфер е да предотврати повреда на данните;
Буферът за вмъкване – такъв буфер се използва от InnoDB за буфериране на актуализации на една и съща страница, така че да могат да се извършват наведнъж, а не една след друга.

Когато се занимавате с големи набори от данни, файлът ibdata1 може да стане изключително голям и това може да бъде сърцевината на много разочароващ проблем - файлът може само да расте и по подразбиране не може да се свива. Можете да изключите MySQL и да изтриете този файл, но това не се препоръчва, освен ако не знаете какво правите. Когато бъде изтрит, MySQL няма да функционира правилно, тъй като речника и системните таблици са изчезнали, така че основната системна таблица е повредена.

За да свиете ibdata1 веднъж завинаги, следвайте тези стъпки:

Изхвърлете всички данни от InnoDB бази данни. Можете да използвате mysqldump или mysqlpump за това действие;
Изхвърлете всички бази данни с изключение на базите данни mysql, performance_schema и information_schema;
Спри MySQL;

Добавете следното към вашия my.cnf файл:

[mysqld]
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT
innodb_log_file_size = 25% of innodb_buffer_pool_size
innodb_buffer_pool_size = up to 60-80% of available RAM.

Изтрийте файловете ibdata1 и ib_logfile* (те ще бъдат пресъздадени при следващото рестартиране на MySQL);
Стартирайте MySQL и възстановете данните от дъмпа, който сте взели преди. След изпълнение на стъпките, описани по-горе, файлът ibdata1 все още ще нараства, но вече няма да съдържа данните от таблици InnoDB - файлът ще съдържа само метаданни и всяка таблица InnoDB ще съществува извън ibdata1. Сега, ако отидете в директорията /var/lib/mysql, ще видите два файла, представляващи всяка таблица, която имате с двигателя InnoDB. Файловете ще изглеждат така:
1. demotable.frm
2. demotable.ibd

Файлът .frm съдържа заглавката на механизма за съхранение, а .ibd файлът съдържа данните за таблицата и индексите на вашата таблица.

Преди да пуснете промените обаче, не забравяйте да настроите фино параметрите според вашата инфраструктура. Тези параметри могат да направят или да нарушат производителността на InnoDB, така че не забравяйте да ги следите по всяко време. Сега трябва да сте готови!

Резюме

За да обобщим, оптимизирането на производителността на InnoDB може да бъде от голяма полза, ако разработвате приложения, които изискват цялост на данните и висока производителност в същото време - InnoDB ви позволява да промените колко памет е разрешена на двигателя consume, за да промените размера на регистрационния файл, метода на flush, който използва двигателят и така нататък - тези промени могат да накарат InnoDB да работи изключително добре, ако са настроени правилно. Преди да извършите каквито и да било подобрения обаче, пазете се от последствията от вашите действия както за вашия сървър, така и за MySQL.

Както винаги, преди да оптимизирате нещо за производителност, винаги правете (и тествайте!) архивни копия, за да можете да възстановите данните си, ако е необходимо, и винаги да тествате всички промени на локален сървър, преди да пуснете промените в производството.