Справяне с MySQL продължителни заявки

Дълго изпълняваните заявки/изявления/транзакции понякога са неизбежни в MySQL среда. В някои случаи продължителната заявка може да бъде катализатор за катастрофално събитие. Ако ви е грижа за вашата база данни, оптимизирането на производителността на заявките и откриването на продължителни заявки трябва да се извършват редовно. Нещата стават по-трудни обаче, когато участват множество екземпляри в група или клъстер.

Когато работим с множество възли, повтарящите се задачи за проверка на всеки един възел са нещо, което трябва да избягваме. ClusterControl наблюдава множество аспекти на вашия сървър на база данни, включително заявки. ClusterControl агрегира цялата информация, свързана със заявката от всички възли в групата или клъстера, за да осигури централизиран изглед на работното натоварване. Точно там има чудесен начин да разберете своя клъстер като цяло с минимални усилия.

В тази публикация в блога ви показваме как да откривате дългосрочни заявки на MySQL с помощта на ClusterControl.

Защо една заявка отнема повече време?

На първо място, трябва да знаем естеството на заявката, независимо дали се очаква да бъде продължителна или краткотрайна заявка. Предполага се, че някои аналитични и пакетни операции са продължителни заявки, така че можем да ги пропуснем засега. Освен това, в зависимост от размера на таблицата, промяната на структурата на таблицата с команда ALTER може да бъде продължителна операция.

За краткосрочна транзакция тя трябва да се изпълни възможно най-бързо, обикновено за няколко секунди. Колкото по-кратък, толкова по-добре. Това идва с набор от правила за най-добри практики за заявки, които потребителите трябва да спазват, като използване на правилно индексиране в израза WHERE или JOIN, използване на правилната машина за съхранение, избор на правилни типове данни, планиране на пакетната операция в извън пиковите часове, разтоварване на аналитични /отчитане на трафика към специални реплики и т.н.

Има редица неща, които могат да доведат до по-дълго изпълнение на заявката:

Неефективна заявка – Използвайте неиндексирани колони при търсене или присъединяване, така че MySQL отнема повече време, за да съответства на условието.
Заключване на таблицата – Таблицата е заключена чрез глобално заключване или изрично заключване на таблицата, когато заявката се опитва да осъществи достъп до нея.
Застой – Заявка изчаква за достъп до същите редове, които са заключени от друга заявка.
Наборът от данни не се вписва в RAM – Ако данните от работния ви набор се вписват в този кеш, тогава заявките SELECT обикновено ще бъдат относително бързи.
Неоптимални хардуерни ресурси – Това може да са бавни дискове, възстановяване на RAID, наситена мрежа и др.
Операция по поддръжката – Изпълнението на mysqldump може да донесе огромни количества иначе неизползвани данни в буферния пул и в същото време (потенциално полезни) данни, които вече са там, ще бъдат изгонени и прехвърлени на диск.

Горният списък подчертава, че не само самата заявка причинява всякакви проблеми. Има много причини, които изискват разглеждане на различни аспекти на MySQL сървър. В някои по-лоши случаи, продължителна заявка може да причини тотално прекъсване на услугата, като спиране на сървъра, срив на сървъра и изчерпване на връзките. Ако видите, че изпълнението на заявка отнема повече време от обикновено, проучете я.

Как да проверя?

СПИСЪК НА ПРОЦЕСИТЕ

MySQL предоставя редица вградени инструменти за проверка на продължителната транзакция. На първо място, командите SHOW PROCESSLIST или SHOW FULL PROCESSLIST могат да разкрият изпълняваните заявки в реално време. Ето екранна снимка на функцията ClusterControl Running Queries, подобна на командата SHOW FULL PROCESSLIST (но ClusterControl обединява целия процес в един изглед за всички възли в клъстера):

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

Регистър на бавените заявки

Регистърът на бавните заявки улавя бавни заявки (SQL изрази, които отнемат повече от long_query_time секунди за изпълнение) или заявки, които не използват индекси за справки (log_queries_not_using_indexes ). Тази функция не е активирана по подразбиране и за да я активирате, просто задайте следните редове и рестартирайте MySQL сървъра:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

Бавният регистър на заявките може да се използва за намиране на заявки, които отнемат много време за изпълнение и следователно са кандидати за оптимизация. Въпреки това, разглеждането на дълъг бавен дневник на заявки може да бъде отнемаща време задача. Има инструменти за анализиране на MySQL бавни регистрационни файлове на заявки и обобщаване на съдържанието им като mysqldumpslow, pt-query-digest или ClusterControl Top Queries.

ClusterControl Top Queries обобщава бавната заявка, използвайки два метода - MySQL дневник на бавните заявки или Схема на производителност:

Можете лесно да видите обобщение на нормализираните обобщения на изявленията, сортирани въз основа на редица критерии:

Хост
Среща
Общо време за изпълнение
Максимално време за изпълнение
Средно време за изпълнение
Време на стандартно отклонение

Разгледахме тази функция много подробно в тази публикация в блога, Как да използвате ClusterControl Query Monitor за MySQL, MariaDB и Percona Server.

Схема за изпълнение

Performance Schema е чудесен инструмент, наличен за наблюдение на вътрешните елементи на MySQL Server и детайлите за изпълнение на по-ниско ниво. Следните таблици в Схемата на производителността могат да се използват за намиране на бавни заявки:

events_statements_current
events_statements_history
events_statements_history_long
events_statements_summary_by_digest
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

MySQL 5.7.7 и по-нови версии включват sys схемата, набор от обекти, които помагат на администраторите на база данни и разработчиците да тълкуват данните, събрани от схемата за ефективност, в по-лесно разбираема форма. Обектите на Sys схема могат да се използват за типични случаи на използване на настройка и диагностика.

ClusterControl предоставя съветници, които са мини-програми, които можете да пишете с помощта на ClusterControl DSL (подобно на JavaScript), за да разширите възможностите за наблюдение на ClusterControl, персонализирани според вашите нужди. Включени са редица скриптове, базирани на схема на производителност, които можете да използвате за наблюдение на производителността на заявката, като изчакване на вход/изход, време за изчакване на заключване и т.н. Например под Управление -> Студио за програмисти , отидете на s9s -> mysql -> p_s -> top_tables_by_iowait.js и щракнете върху бутона "Компилиране и стартиране". Трябва да видите изхода в раздела Съобщения за топ 10 таблици, сортирани по I/O чакане на сървър:

Има редица скриптове, които можете да използвате, за да разберете информация от ниско ниво къде и защо се случва забавянето като top_tables_by_lockwait.js , top_accessed_db_files.js и така нататък.

ClusterControl – Откриване и предупреждаване при продължителни заявки

С ClusterControl ще получите допълнителни мощни функции, които няма да намерите в стандартната инсталация на MySQL. ClusterControl може да бъде конфигуриран да наблюдава проактивно работещите процеси и да повдига аларма и да изпраща известия до потребителя, ако е надвишен прагът за дълга заявка. Това може да се конфигурира с помощта на конфигурацията по време на изпълнение в Настройки:

За pre1.7.1, стойността по подразбиране за query_monitor_alert_long_running_query е невярно. Ние насърчаваме потребителя да активира това, като го зададе на 1 (true). За да го направите постоянен, добавете следния ред в /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Всички промени, направени в конфигурацията по време на изпълнение, се прилагат незабавно и не се изисква рестартиране. Ще видите нещо подобно под секцията Аларми, ако заявка надвиши праговете от 30 000 мс (30 секунди):

Ако конфигурирате настройките на получателя на поща като „Достави“ за категорията на сериозност DbComponent плюс КРИТИЧНА (както е показано на следната екранна снимка):

Трябва да получите копие от тази аларма във вашия имейл. В противен случай той може да бъде препратен ръчно, като щракнете върху бутона „Изпращане на имейл“.

Освен това можете да филтрирате всякакъв вид ресурси на списък с процеси, които отговарят на определени критерии с регулярен израз (regex). Например, ако искате ClusterControl да открие продължителна заявка за трима потребители на MySQL, наречени 'sbtest', 'myshop' и 'db_user1', трябва да направи следното:

Всички промени, направени в конфигурацията по време на изпълнение, се прилагат незабавно и не се изисква рестартиране.

Освен това ClusterControl ще изброи всички транзакции в застой заедно със състоянието на InnoDB, когато се е случвало под Производителност -> Регистър на транзакциите :

Тази функция не е активирана по подразбиране, поради откриването на блокиране ще повлияе на използването на процесора на възлите на базата данни. За да го активирате, просто поставете отметка в квадратчето „Активиране на дневника на транзакциите“ и посочете интервала, който искате. За да го направите постоянен, добавете променлива със стойност в секунди в /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

По същия начин, ако искате да проверите състоянието на InnoDB, просто отидете на Ефективност -> Статус на InnoDB и изберете MySQL сървъра от падащото меню. Например:

Ето го – цялата необходима информация може лесно да бъде извлечена с няколко щраквания.

Резюме

Дългосрочните транзакции могат да доведат до влошаване на производителността, спиране на сървъра, максимално изчерпване на връзките и блокиране. С ClusterControl можете да откривате продължително изпълнявани заявки директно от потребителския интерфейс, без да е необходимо да проверявате всеки отделен MySQL възел в клъстера.