Най-големите дни за онлайн пазаруване в годината са точно зад ъгъла. Готова ли е вашата база данни? Чрез настройка на 20 ключови системни променливи MariaDB, вие ще подобрите производителност на вашата база данни ,мащабируемост иналичност , като се гарантира, че всеки потенциален клиент има гладко потребителско изживяване. Следните системни променливи се появяват многократно при конфигурирането на оптимална сървърна среда на MariaDB. Приложете нашите препоръки за най-настроените стойности и направете тазгодишния период Черен петък – Кибер понеделник в най-добрия си досегашния период.
Няколко важни бележки:
- Не приемайте тези предложения сляпо. Всяка среда на MariaDB е уникална и изисква допълнително обмисляне, преди да направите каквито и да било промени. Най-вероятно ще трябва да коригирате тези настройки за вашия специфичен случай на употреба и среда.
- Конфигурационният файл на MariaDB се намира в /etc/my.cnf. Всеки път, когато променяте този файл, ще трябва да рестартирате услугата MySQL, за да влязат в сила новите промени.
20 препоръки за настройка за Черен петък и Кибер понеделник
1. Размер на буферния пул на InnoDBа
Размерът на буферния пул на InnoDB това е настройка №1, която трябва да гледате за всяка инсталация, използваща InnoDB. Буферният пул е мястото, където се кешират данни и индекси; като го имате възможно най-голям, ще гарантира, че използвате памет, а не дискове за повечето операции за четене.
2. Размер на регистрационния файл на InnoDBа
innodb_log-file-size е размерът на регистрационните файлове за повторно изпълнение, които се използват, за да се гарантира, че записите са бързи и издръжливи. Има две общи предложения за оразмеряване на регистрационните файлове на InnoDB:
- Задайте комбиниран общ размер на InnoDB регистрационни файлове, по-голям от 25–50% от размера на буферния пул на InnoDB
или
- Задайте комбиниран размер на регистрационния файл на InnoDB, равен на записите в регистрационния файл за един час по време на пиково натоварване
По-големите регистрационни файлове могат да доведат до по-бавно възстановяване в случай на срив на сървъра. Те обаче също намаляват броя на необходимите контролни точки и намаляват I/O на диска.
Оценете размера на бинарните регистрационни файлове за един час при оперативно натоварване, след което решете дали да увеличите размера на регистрационните файлове на InnoDB.
Получаването на правилните размери на регистрационните файлове на innodb е важно за постигане на добра производителност на системата. Двигателят за съхранение InnoDB на MariaDB използва фиксиран размер (кръгло) пространство на дневника за повторение. Размерът се контролира от innodb_log_file_size и innodb_log_files_in_group (по подразбиране 2). Умножете тези стойности, за да получите наличното за използване пространство в регистъра за повторение. Макар че технически няма значение дали използвате променливата innodb_log_file_size или innodb_log_files_in_group, за да контролирате размера на пространството за повторно изпълнение, повечето хора просто работят с innodb_log_file_size и оставят innodb_log_files_in_group сами.
Размерът на пространството за повторно изпълнение на InnoDB е една от най-важните опции за конфигурация за натоварвания с интензивно писане. Това обаче идва с компромиси. Колкото повече пространство за повторно изпълнение е конфигурирано, толкова по-добре InnoDB може да оптимизира I/O запис. Увеличаването на пространството за повторно изпълнение обаче означава и по-дълги времена за възстановяване, когато системата загуби захранване или се срине по други причини.
3. Размер на буфера на журнала InnoDB
По-големият размер на буфера на регистрационните файлове на InnoDB означава по-малко I/O диск за по-големи транзакции. Препоръчва се да зададете това на 64M на всички сървъри.
4. Интервал за изчистване на лог InnoDB
Променливата innodb_flush_log_at_trx_commit контролира променливата, когато се извършва прочистване на буфера на журнала към диска. innodb_flush_log_at_trx_commit =1 (по подразбиране) изтрива буфера на журнала на диск при всяко комитиране на транзакция. Това е най-безопасната, но и най-малко ефективната опция.
innodb_flush_log_at_trx_commit =0 изтрива буфера на журнала на диск всяка секунда, но нищо при записване на транзакция. Може да бъде загубена до една секунда (вероятно повече поради планиране на процеса). Ако има някакъв срив, MySQL или сървърът могат да загубят данни. Това е най-бързия, но най-малко безопасна опция.
innodb_flush_log_at_trx_commit =2 записва буфера на журнала във файл при всяко записване, но изхвърля на диск всяка секунда. Ако дисковият кеш има резервно копие на батерията (например батериен кеш контролер за кеш raid), това обикновено е най-добрият баланс между производителност и безопасност. Срив на MySQL не трябва да губи данни. Срив на сървъра или прекъсване на захранването може да загуби до секунда (вероятно повече поради планиране на процеса). Кеш с батерии намалява тази възможност.
Препоръчваме да използвате първата опция за безопасност.
5. InnoDB IO Capacity
innodb_io_capacity трябва да се настрои на приблизително максималния брой IOPS, който основното хранилище може да обработи.
По подразбиране това е зададено на 1000. Препоръчваме да направите сравнителен анализ на хранилището, за да определите дали можете да увеличите тази стойност допълнително.
6. Размер на кеша на нишкита
Наблюдавайте стойността на Threads_created. Ако продължава да се увеличава с повече от няколко нишки в минута, увеличете стойността на thread_cache_size.
Размерът на кеша на нишката е зададен на 200 в текущата конфигурация по подразбиране.
7. Кеш на таблици и кеш за дефиниции на таблици
Променливите table_open_cache и table_defintion_cache контролират броя на таблиците и дефинициите, за да останат отворени за всички нишки.
Наблюдавайте Open_tables, Open_table_definitions, Opened_tables и Opened_table_definitions, за да определите най-добрата стойност. Общото предложение е да зададете table_open_cache (и впоследствие table_definition_cache) само достатъчно високо, за да намалите скоростта на нарастване на стойността на състоянието Opened_tables (и Opened_table_definitions).
И table_open_cache, и table_defintion_cache са зададени на 2048 в конфигурацията по подразбиране.
8. Кеш на заявката
Кешът на заявките е добре известно препятствие, което може да се види дори когато паралелността е умерена. Най-добрият вариант е да го деактивирате от първия ден като зададете query_cache_size =0 (по подразбиране в MariaDB 10) и да използвате други начини за ускоряване на заявките за четене:добро индексиране, добавяне на реплики за разпределяне на натоварването за четене или използване на външен кеш ( memcache или redis, например). Ако вече сте изградили своето приложение MariaDB с активиран кеш на заявки и никога не сте забелязали никакъв проблем, кешът на заявките може да е от полза за вас. В такъв случай бъдете внимателни, ако решите да го деактивирате.
9. Временни таблици, tmp_table_size и max_heap_table_size
MySQL използва по-ниската от max_heap_table_size и tmp_table_size, за да ограничи размера на временните таблици в паметта. Това са променливи за всеки клиент. Макар че тази стойност е голяма може да помогне за намаляване на броя на временните таблици, създадени на диска, това също повишава риска от достигане на капацитета на паметта на сървъра, тъй като това е на клиент. Обикновено 32M до 64M е предполагаемата стойност за начало и за двете променливи и за настройка, ако е необходимо.
Временните таблици често се използват за GROUP BY, ORDER BY, DISTINCT, UNION, подзаявки и т.н. В идеалния случай MySQL трябва да ги създава в паметта, с възможно най-малко на диска.
Важно е да се отбележи, че заявките, които не използват правилно обединения и създаването на големи временни таблици, могат да бъдат една от причините за по-голям брой временни таблици на диска. Друга причина е, че механизмът за съхранение на паметта използва колони с фиксирана дължина и приема най-лошия сценарий. Ако колоните не са оразмерени правилно (например VARCHAR(255) за кратък низ), това влияе върху размера на таблицата в паметта и може да накара тя да отиде на диска по-рано, отколкото трябва. Освен това временните таблици с blob и текстови колони незабавно ще отидат на диск, тъй като механизмът за съхранение на паметта не ги поддържа.
И двете в момента са настроени на 64M по подразбиране.
10. Ниво на дневник за предупреждениете
Препоръчваме да зададете това ниво на регистрационния файл за предупреждения на log_warnings =2. По този начин се регистрира информация за прекъснати връзки и грешки с отказан достъп.
11. Макс. връзки
Ако често се сблъсквате с грешката „Твърде много връзки“, max_connections е твърде ниска. Често, тъй като приложението не затваря правилно връзките към базата данни, имате нужда от много повече от стандартните 151 връзки. Основният недостатък на високите стойности за max_connections (да речем, 1000 или повече) е, че сървърът ще престане да реагира ако трябва да изпълнява толкова много активни транзакции. Използването на пул за връзки на ниво приложение или пул от нишки на ниво MariaDB може да помогне тук.
12. Изолация на транзакците
Проучете наличните нива на изолация на транзакции и определете най-добрата изолация на транзакциите за случая на използване на вашия сървър.
13. Двоичен регистрационен формат
Препоръчваме да използвате редовия двоичен регистрационен формат за репликация главен-главен.
14. Автоматично увеличаване на изместванията
За да се намали вероятността от сблъсък между два главни устройства да бъдат записани едновременно, стойностите за автоматично увеличение и изместване на автоматично увеличение трябва да бъдат съответно коригирани.
15. Синхронизиране на Binlogа
По подразбиране операционната система обработва изтриването на binlog на диск. В случай на срив на сървъра е възможно да загубите транзакции от двоичния регистрационен файл, което да доведе до изключване на репликацията. Настройката sync_binlog =1 води до изтриване на binlog файла при всяко записване.
Това е по-бавно, но най-безопасният вариант.
16. Безопасни от срив(r) Slavesи
За да избегнете грешки при репликация след подчинен срив, активирайте възстановяването на релейния регистрационен файл и синхронизирането на регистрационния файл на релето и информационните файлове на релейния регистрационен файл с диска.
17. Регистрирайте подчинени актуализации
За да имате верижна репликация (главен -> подчинен -> подчинен), log_slave_updates трябва да бъдат активирани. Това казва на подчинения да запише репликирани транзакции в собствения си двоичен дневник, за да могат след това да бъдат репликирани на подчинени от него.
18. Подчинени устройства само за четене
Подробните устройства трябва да са само за четене, за да се избегне случайно записване на данни в тях.
Забележка :Потребителите със супер привилегии все още могат да пишат, когато сървърът е само за четене.
19. Време за изчакване на подчинената мрежата
Променливата slave_net_timeout е броят секунди, през които ведомото устройство ще изчака пакет от главния, преди да се опита да се свърже отново. По подразбиране е 3600 (1 час). Това означава, че ако връзката падне и не бъде открита, може да мине до един час, преди подчинената да се свърже отново. Това може да доведе до внезапно подчинение да изостане с до един час от хозяина.
Препоръчваме да зададете slave_net_timeout на по-разумна стойност, като 30 или 60.
20. Гледайте нашия уебинар за подготовка за черен петък и кибер понеделник
Гледайте нашия уебинар при поискване – Подготовка за Черен петък и Кибер понеделник – за да научите четирите жизненоважни принципа за готовност на базата данни: мерки за сигурност за защита на вашата база данни от злонамерени атаки, настройка на производителността за да гарантирате, че предоставяте гладко потребителско изживяване, стратегии за висока наличност за да сте сигурни, че няма да пропуснете нито една продажба и мащабируемост за да се подготви както за очакван растеж, така и за неочаквани скокове.
