Още откакто MySQL първоначално беше разклонен, за да формира MariaDB, той беше широко поддържан и приет бързо от голяма аудитория в общността на базата данни с отворен код. Първоначално заместващ го, MariaDB започна да създава разлика срещу MySQL, особено с пускането на MariaDB 10.2.
Въпреки това, обаче, все още няма реална издайнически разлика между MariaDB и MySQL, тъй като и двете имат двигатели, които са съвместими и могат да работят естествено един с друг. Така че не се изненадвайте, ако настройката на вашата настройка на MariaDB има подобен подход към една настройка на MySQL.
Този блог ще обсъди настройката на MariaDB, по-специално тези системи, работещи в Linux среда.
Оптимизация на хардуера и системата на MariaDB
MariaDB препоръчва да подобрите хардуера си в следния приоритетен ред...
Памет
Паметта е най-важният фактор за базите данни, тъй като ви позволява да коригирате системните променливи на сървъра. Повече памет означава по-големи кешове на ключове и таблици, които се съхраняват в паметта, така че дисковете да имат достъп, с порядък по-бавно, впоследствие намаляват.
Имайте предвид обаче, че простото добавяне на повече памет може да не доведе до драстични подобрения, ако сървърните променливи не са настроени да използват допълнителната налична памет.
Използването на повече RAM слотове на дънната платка увеличава честотата на шината и ще има повече латентност между RAM и процесора. Това означава, че използването на най-високия размер на RAM на слот е за предпочитане.
Дискове
Бързият достъп до диска е от решаващо значение, тъй като в крайна сметка това е мястото, където се намират данните. Ключовата цифра е времето за търсене на диска (измерване на това колко бързо може да се движи физическият диск за достъп до данните), така че изберете дискове с възможно най-малко време за търсене. Можете също да добавите специални дискове за временни файлове и регистрационни файлове за транзакции.
Бърз Ethernet
С подходящите изисквания за вашата интернет честотна лента, бързият ethernet означава, че може да има по-бърз отговор на клиентски заявки, време за реакция на репликация за четене на двоични регистрационни файлове в подчинените устройства, по-бързото време за реакция също е много важно, особено при Galera -базирани клъстери.
ЦП
Въпреки че хардуерните тесни места често се намират другаде, по-бързите процесори позволяват изчисленията да се извършват по-бързо и резултатите да се изпращат обратно на клиента по-бързо. Освен скоростта на процесора, скоростта на шината на процесора и размерът на кеша също са важни фактори, които трябва да се вземат предвид.
Настройване на вашия Disk I/O Scheduler
I/O планировчиците съществуват като начин за оптимизиране на заявките за достъп до диск. Той обединява I/O заявки към подобни места на диска. Това означава, че дисковото устройство не трябва да търси толкова често и подобрява огромното общо време за реакция и спестява операции с диск. Препоръчителните стойности за I/O производителност са noop и крайния срок.
noop е полезен за проверка дали сложните решения за I/O планиране на други планировчици не причиняват регресия на I/O производителността. В някои случаи може да бъде полезно за устройства, които сами планират I/O, като интелигентно съхранение или устройства, които не зависят от механично движение, като SSD. Обикновено планировщикът за I/O DEADLINE е по-добър избор за тези устройства, но поради по-малко режийни разходи NOOP може да доведе до по-добра производителност при определени натоварвания.
За крайния срок това е I/O планировчик, ориентиран към забавяне. Всяка I/O заявка има определен краен срок. Обикновено заявките се съхраняват в опашки (четене и запис), сортирани по номера на сектори. Алгоритъмът на DEADLINE поддържа две допълнителни опашки (четене и запис), където заявките се сортират по краен срок. Докато нито една заявка не е изтекла, се използва опашката „сектор“. Ако възникнат изчаквания, заявките от опашката „краен срок“ се обслужват, докато няма повече изтекли заявки. Обикновено алгоритъмът предпочита четене пред записване.
За PCIe устройства (NVMe SSD устройства) те имат свои собствени големи вътрешни опашки заедно с бързо обслужване и не изискват или се възползват от настройка на I/O планировчик. Препоръчително е да нямате изричен конфигурационен параметър в режим на планиране.
Можете да проверите настройките на вашия планировчик с:
cat /sys/block/${DEVICE}/queue/schedulerНапример, трябва да изглежда така:
cat /sys/block/sda/queue/scheduler
[noop] deadline cfqЗа да го направите постоянен, редактирайте /etc/default/grub конфигурационния файл, потърсете променливата GRUB_CMDLINE_LINUX и добавете асансьор точно както по-долу:
GRUB_CMDLINE_LINUX="elevator=noop"Увеличете лимита за отваряне на файлове
За да се гарантира добра производителност на сървъра, общият брой клиентски връзки, файлове с база данни и регистрационни файлове не трябва да надвишава максималното ограничение на файловия дескриптор на операционната система (ulimit -n). Linux системите ограничават броя на файловите дескриптори, които всеки процес може да отвори до 1024 на процес. На активни сървъри на бази данни (особено производствените) може лесно да достигне системния лимит по подразбиране.
За да увеличите това, редактирайте /etc/security/limits.conf и укажете или добавете следното:
mysql soft nofile 65535
mysql hard nofile 65535Това изисква рестартиране на системата. След това можете да потвърдите, като изпълните следното:
$ ulimit -Sn
65535
$ ulimit -Hn
65535По избор можете да зададете това чрез mysqld_safe, ако стартирате процеса на mysqld чрез mysqld_safe,
[mysqld_safe]
open_files_limit=4294967295или ако използвате systemd,
sudo tee /etc/systemd/system/mariadb.service.d/limitnofile.conf <<EOF
[Service]
LimitNOFILE=infinity
EOF
sudo systemctl daemon-reloadНастройка на Swappiness на Linux за MariaDB
Linux Swap играе голяма роля в системите за бази данни. Действа като резервната ви гума в автомобила ви, когато неприятните течове на памет пречат на работата ви, машината ще се забави... но в повечето случаи все пак ще може да се използва, за да завърши възложената си задача.
За да приложите промените към вашата размяна, просто стартирайте,
sysctl -w vm.swappiness=1Това се случва динамично, без да е необходимо да рестартирате сървъра. За да го направите постоянен, редактирайте /etc/sysctl.conf и добавете реда,
vm.swappiness=1Доста обичайно е да зададете swappiness=0, но след пускането на нови ядра (т.е. ядра> 2.6.32-303) бяха направени промени, така че трябва да зададете vm.swappiness=1.
Оптимизации на файловата система за MariaDB
Най-често срещаните файлови системи, използвани в Linux среди, работещи с MariaDB, са ext4 и XFS. Налични са и определени настройки за внедряване на архитектура с помощта на ZFS и BRTFS (както е посочено в документацията на MariaDB).
В допълнение към това, повечето настройки на базата данни не трябва да записват времето за достъп до файловете. Може да искате да деактивирате това, когато монтирате тома в системата. За да направите това, редактирайте вашия файл /etc/fstab. Например, на том с име /dev/md2, това изглежда така:
/dev/md2 / ext4 defaults,noatime 0 0Създаване на оптимален екземпляр на MariaDB
Съхранявайте данните в отделен том
Винаги е идеално да разделите данните на базата си данни на отделен том. Този том е специално за тези видове бързи обеми за съхранение като SSD, NVMe или PCIe карти. Например, ако целият ви системен обем се повреди, обемът на вашата база данни ще бъде безопасен и бъдете сигурни, че няма да бъде засегнат, в случай че хардуерът ви за съхранение ще се повреди.
Настройте MariaDB за ефективно използване на паметта
innodb_buffer_pool_size
Основната стойност за коригиране на сървър на база данни с изцяло/предимно XtraDB/InnoDB таблици може да бъде зададена до 80% от общата памет в тези среди. Ако е зададено на 2 GB или повече, вероятно ще искате да коригирате и innodb_buffer_pool_instances. Можете да зададете това динамично, ако използвате MariaDB>=10.2.2 версия. В противен случай се изисква рестартиране на сървъра.
tmp_memory_table_size/max_heap_table_size
За tmp_memory_table_size (tmp_table_size), ако имате работа с големи временни таблици, настройката на това по-високо осигурява печалби в производителността, тъй като ще се съхранява в паметта. Това е често срещано при заявки, които силно използват GROUP BY, UNION или подзаявки. Въпреки че ако max_heap_table_size е по-малък, долната граница ще се приложи. Ако дадена таблица надвишава ограничението, MariaDB я преобразува в таблица MyISAM или Aria. Можете да видите дали е необходимо да се увеличи, като сравните променливите на състоянието Created_tmp_disk_tables и Created_tmp_tables, за да видите колко временни таблици от общо създаденото трябва да бъдат преобразувани в диск. Често сложните заявки GROUP BY са отговорни за превишаването на лимита.
Докато max_heap_table_size, това е максималният размер за създадените от потребителя таблици MEMORY. Стойността, зададена на тази променлива, е приложима само за новосъздадените или повторно създадени таблици, а не за съществуващите. По-малката от max_heap_table_size и tmp_table_size също ограничава вътрешните таблици в паметта. Когато се достигне максималният размер, всички по-нататъшни опити за вмъкване на данни ще получат грешка "таблицата ... е пълна". Временните таблици, създадени с CREATE TEMPORARY, няма да бъдат преобразувани в Aria, както се случва с вътрешните временни таблици, но също така ще получат грешка за пълната таблица.
innodb_log_file_size
Големите памети с високоскоростна обработка и бърз I/O диск не са нови и имат разумна цена, както препоръчва. Ако предпочитате повече печалби в производителността, особено по време и обработката на вашите InnoDB транзакции, задаване на променливата innodb_log_file_size на по-голяма стойност като 5Gib или дори 10GiB е разумно. Увеличаването означава, че по-големите транзакции могат да се изпълняват, без да е необходимо да се извършват дискови I/O преди извършване.
размер_на_буфера
В някои случаи във вашите заявки обикновено липсва подходящо индексиране или просто има случаи, в които се нуждаете от тази заявка, за да изпълните. Не, освен ако няма да бъде силно извиквана или извиквана от гледна точка на клиента, настройката на тази променлива е най-добра на ниво сесия. Увеличете го, за да получите по-бързо пълни обединявания, когато добавянето на индекси не е възможно, въпреки че имайте предвид проблемите с паметта, тъй като присъединяванията винаги ще разпределят минималния размер.
Задайте своя max_allowed_packet
MariaDB има същата природа като MySQL при обработка на пакети. Той разделя данните на пакети и клиентът трябва да е наясно със стойността на променливата max_allowed_packet. Сървърът ще има буфер за съхраняване на тялото с максимален размер, съответстващ на тази стойност max_allowed_packet. Ако клиентът изпрати повече данни от max_allowed_packet size, сокетът ще бъде затворен. Директивата max_allowed_packet определя максималния размер на пакета, който може да бъде изпратен.
Задаването на тази стойност твърде ниска може да доведе до спиране на заявка и затваряне на нейната клиентска връзка, което е доста често срещано за получаване на грешки като ER_NET_PACKET_TOO_LARGE или Загубена връзка с MySQL сървър по време на заявка. В идеалния случай, особено при повечето изисквания на приложенията днес, можете да започнете да задавате това на 512MiB. Ако това е тип приложение с ниско търсене, просто използвайте стойността по подразбиране и задайте тази променлива само чрез сесия, когато е необходимо, ако данните за изпращане или получаване са твърде големи от стойността по подразбиране (16MiB от MariaDB 10.2.4). При определени натоварвания, които изискват обработка на големи пакети, тогава трябва да настроите по-високото му според нуждите си, особено когато сте в репликация. Ако max_allowed_packet е твърде малък на подчинения, това също кара подчинения да спре I/O нишката.
Използване на Threadpool
В някои случаи тази настройка може да не е необходима или препоръчана за вас. Threadpools са най-ефективни в ситуации, когато заявките са сравнително кратки и натоварването е свързано с процесора (OLTP работни натоварвания). Ако работното натоварване не е обвързано с процесора, все пак може да искате да ограничите броя на нишките, за да спестите памет за буферите на паметта на базата данни.
Използването на пул на нишки е идеално решение, особено ако системата ви изпитва превключване на контекста и намирате начини да намалите това и да поддържате по-малък брой нишки от броя на клиентите. Този брой обаче също не трябва да е твърде малък, тъй като ние също искаме да използваме максимално наличните процесори. Следователно в идеалния случай трябва да има една активна нишка за всеки процесор на машината.
Можете да зададете thread_pool_max_threads, thread_pool_min_threads за максималния и минималния брой нишки. За разлика от MySQL, това присъства само в MariaDB.
Задайте променливата thread_handling, която определя как сървърът обработва нишки за клиентски връзки. В допълнение към нишките за клиентски връзки, това важи и за определени вътрешни нишки на сървъра, като нишки за подчинени на Galera.
Настройте кеша на вашата таблица + max_connections
Ако се сблъсквате от време на време в списъка с процеси за статуси на отваряне на таблици и затваряне на таблици, това може да означава, че трябва да увеличите кеша на таблиците. Можете да наблюдавате това и чрез подканата на mysql клиента, като изпълните SHOW GLOBAL STATUS LIKE 'Open%table%'; и наблюдавайте променливите на състоянието.
За max_connections, ако приложението ви изисква много едновременни връзки, можете да започнете да задавате това на 500.
За table_open_cache това ще бъде общият брой на вашите таблици, но е най-добре да добавите повече в зависимост от типа на заявките, които обслужвате, тъй като временните таблици също ще бъдат кеширани. Например, ако имате 500 таблици, би било разумно да започнете с 1500.
Докато вашите table_open_cache_instances започнете да го настройвате на 8. Това може да подобри мащабируемостта чрез намаляване на споровете между сесиите, кешът на отворените таблици може да бъде разделен на няколко по-малки екземпляра на кеша с размер table_open_cache / table_open_cache_instances.
За InnoDB, table_definition_cache действа като меко ограничение за броя на отворените екземпляри на таблица в кеша на речника на InnoDB данни. Стойността, която трябва да бъде дефинирана, ще зададе броя дефиниции на таблици, които могат да бъдат съхранени в кеша на дефинициите. Ако използвате голям брой таблици, можете да създадете голям кеш за дефиниции на таблица, за да ускорите отварянето на таблици. Кешът на дефинициите на таблицата заема по-малко място и не използва файлови дескриптори, за разлика от нормалния кеш на таблицата. Минималната стойност е 400. Стойността по подразбиране се основава на следната формула, ограничена до лимит от 2000:
MIN(400 + table_open_cache / 2, 2000)Ако броят на отворените екземпляри на таблица надвишава настройката table_definition_cache, механизмът LRU започва да маркира екземпляри на таблица за изгонване и в крайна сметка ги премахва от кеша на речника на данните. Ограничението помага за справяне със ситуации, при които значителни количества памет биха били използвани за кеширане на рядко използвани екземпляри на таблица до следващото рестартиране на сървъра. Броят на екземпляри на таблица с кеширани метаданни може да е по-висок от ограничението, определено от table_definition_cache, тъй като екземпляри на родителска и дъщерна таблица с връзки с външни ключове не се поставят в списъка LRU и не подлежат на изгонване от паметта.
За разлика от table_open_cache, table_definition_cache не използва файлови дескриптори и е много по-малък.
Справяне с кеша на заявки
За предпочитане, препоръчваме да деактивирате кеша на заявки във всичките си настройки на MariaDB. Трябва да се уверите, че query_cache_type=OFF и query_cache_size=0, за да завършите деактивирането на кеша на заявките. За разлика от MySQL, MariaDB все още напълно поддържа кеша на заявки и няма никакви планове за оттегляне на поддръжката си за използване на кеша на заявки. Има някои хора, които твърдят, че кешът на заявките все още им осигурява ползи за производителността. Въпреки това, тази публикация от Percona Кешът на заявките на MySQL:Най-лошият враг или най-добрият приятел разкрива, че кешът на заявките, ако е активиран, води до излишни разходи и показва лоша производителност на сървъра.
Ако възнамерявате да използвате кеша на заявките, уверете се, че наблюдавате кеша на заявките си, като изпълните SHOW GLOBAL STATUS LIKE 'Qcache%';. Qcache_inserts съдържа броя на заявките, добавени към кеша на заявките, Qcache_hits съдържа броя на заявките, които са използвали кеша на заявките, докато Qcache_lowmem_prunes съдържа броя на заявките, които са изхвърлени от кеша поради липса на памет. Докато е навреме, използването и разрешаването на кеша на заявки може да стане фрагментирано. Високото ниво на Qcache_free_blocks спрямо Qcache_total_blocks може да показва фрагментация. За да го дефрагментирате, стартирайте FLUSH QUERY CACHE. Това ще дефрагментира кеша на заявките, без да изпуска никакви заявки.
Винаги наблюдавайте сървърите си
Изключително важно е да наблюдавате правилно своите възли на MariaDB. Общите инструменти за наблюдение (като Nagios, Zabbix или PMM) са налични, ако предпочитате безплатни инструменти с отворен код. За корпоративни и напълно опаковани инструменти ви предлагаме да опитате ClusterControl, тъй като той не само осигурява наблюдение, но също така предлага съвети за ефективност, сигнали и аларми, които ви помагат да подобрите производителността на вашата система и да сте в крак с текущите тенденции, докато се ангажирате с екипа за поддръжка. Мониторингът на бази данни с ClusterControl е безплатен и част от изданието на Общността.
Заключение
Настройката на вашата MariaDB настройка е почти същият подход като MySQL, но с някои различия, тъй като се различава в някои от своите подходи и версии, които поддържа. MariaDB вече е различен обект в света на базата данни и бързо спечели доверието от общността без никакъв FUD. Те имат свои собствени причини защо трябва да се прилага по този начин, така че е много важно да знаем как да настроим това и да оптимизираме вашия MariaDB сървър(и).
