Речник на базата данни на DevOps за начинаещи в MySQL

Когато трябва да работите с база данни, с която не сте запознати на 100%, може да бъдете затрупани от стотиците налични показатели. Кои са най-важните? Какво трябва да наблюдавам и защо? Какви модели в показателите трябва да бият някои алармени камбани? В тази публикация в блога ще се опитаме да ви запознаем с някои от най-важните показатели, които да следите, докато изпълнявате MySQL или MariaDB в производство.

Com_* Броячи на състоянието

Ще започнем с Com_* броячи - те определят броя и видовете заявки, които MySQL изпълнява. Тук говорим за типове заявки като SELECT, INSERT, UPDATE и много други. Много е важно да ги държите под око, тъй като внезапните пикове или неочаквани спадове могат да подсказват, че нещо се е объркало в системата.

Нашата всеобхватна система за управление на база данни ClusterControl ви показва тези данни, свързани с най-често срещаните типове заявки в секцията „Общ преглед“.

Handler_* Броячи на състоянието

Категория показатели, които трябва да следите, са Handler_* броячите в MySQL. Com_* броячите ви казват какви заявки изпълнява вашият MySQL екземпляр, но един SELECT може да бъде напълно различен от друг - SELECT може да бъде търсене на първичен ключ, може да бъде и сканиране на таблица, ако не може да се използва индекс. Манипулаторите ви казват как MySQL осъществява достъп до съхранени данни – това е много полезно за изследване на проблемите с производителността и оценка дали има възможна печалба при преглед на заявки и допълнително индексиране.

Както можете да видите от графиката по-горе, има много показатели за проследяване (и ClusterControl изобразява най-важните) - тук няма да обхванем всички (можете да намерите описания в документацията на MySQL), но бихме искали да подчертаем най-важните.

Handler_read_rnd_next - всеки път, когато MySQL осъществява достъп до ред без търсене в индекс, в последователен ред, този брояч ще се увеличава. Ако във вашето работно натоварване handler_read_rnd_next е отговорен за висок процент от целия трафик, това означава, че вашите таблици най-вероятно биха могли да използват някои допълнителни индекси, тъй като MySQL извършва много сканирания на таблици.

Handler_read_next и handler_read_prev - тези два брояча се актуализират всеки път, когато MySQL извършва индексно сканиране - напред или назад. Handler_read_first и handler_read_last може да хвърлят малко повече светлина върху това какъв вид сканиране на индекс са това - ако говорим за пълно сканиране на индекс (напред или назад), тези два брояча ще бъдат актуализирани.

Handler_read_key – този брояч, от друга страна, ако стойността му е висока, ви казва, че вашите таблици са добре индексирани, тъй като много от редовете са били достъпни чрез търсене в индекс.

Закъснение при репликация

Ако работите с MySQL репликация, забавянето на репликацията е показател, който определено искате да наблюдавате. Закъснението при репликацията е неизбежно и ще трябва да се справите с него, но за да се справите с него, трябва да разберете защо се случва. За това първата стъпка ще бъде да знаете _кога_ се е появил.

Всеки път, когато видите скок на забавянето на репликацията, бихте искали да проверите други графики, за да получите повече улики - защо се е случило това? Какво може да го е причинило? Причините могат да бъдат различни – дълги, тежки DML, значително увеличение на броя на DML, изпълнени за кратък период от време, ограничения на процесора или I/O.

InnoDB I/O

Има редица важни показатели за наблюдение, свързани с I/O.

В графиката по-горе можете да видите няколко метрики, които ви казват какъв вид I/O прави InnoDB - запис и четене на данни, запис на повторен дневник, fsync. Тези показатели ще ви помогнат да решите, например, дали забавянето на репликацията е причинено от скок на I/O или може би поради някаква друга причина. Също така е важно да следите тези показатели и да ги сравнявате с вашите хардуерни ограничения - ако се доближавате до хардуерните ограничения на вашите дискове, може би е време да разгледате това, преди да има по-сериозни ефекти върху производителността на вашата база данни.

Показатели на Galera – Контрол на потока и опашки

Ако случайно използвате Galera Cluster (без значение кой вкус използвате), има още няколко показателя, които бихте искали да наблюдавате внимателно, те са донякъде обвързани. Първите от тях са показатели, свързани с контрола на потока.

Контролът на потока в Galera е средство за поддържане на клъстера в синхрон. Всеки път, когато възелът спре и не може да се справи с останалата част от клъстера, той започва да изпраща съобщения за контрол на потока, като моли останалите възли на клъстера да се забавят. Това му позволява да навакса. Това намалява производителността на клъстера, така че е важно да можете да разберете кой възел и кога е започнал да изпраща съобщения за контрол на потока. Това може да обясни някои от забавянията, изпитвани от потребителите, или да ограничи времевия прозорец и хоста за използване за по-нататъшно разследване.

Вторият набор от показатели за наблюдение са тези, свързани с изпращане и получаване на опашки в Galera.

Възлите на Galera могат да кешират набори за запис (транзакции), ако не могат да приложат всички веднага. Ако е необходимо, те могат също да кешират набори за запис, които предстои да бъдат изпратени до други възли (ако даден възел получи записи от приложението). И двата случая са симптоми на забавяне, което най-вероятно ще доведе до изпращане на съобщения за контрол на потока и изисква известно разследване – защо се е случило, на кой възел, в колко часа?

Това, разбира се, е само върхът на айсберга, когато вземем предвид всички показатели, които MySQL предоставя – все пак няма как да сгрешите, ако започнете да гледате тези, които разгледахме тук, в допълнение към обикновените показатели за ОС/хардуер като CPU , памет, използване на диска и състояние на услугите.