Добавихме редица нови табла за MySQL в най-новата ни версия на ClusterControl 1.7.0. - и в предишния ни блог ви показахме как да наблюдавате своя ProxySQL с Prometheus и ClusterControl.
В този блог ще разгледаме таблото за управление на MySQL Overview.
И така, ние активирахме мониторинга, базиран на агенти, в раздела Табло за управление, за да започне да събира показатели за възлите. Обърнете внимание, че когато активирате мониторинга, базиран на агент, имате опциите да зададете „Интервал за изтриване (секунди) ” и „Запазване на данни (дни) “. Интервалът за изстъргване е мястото, където искате да зададете колко агресивно Prometheus ще събира данни от целта, а запазването на данни е колко дълго искате да съхранявате данните си, събрани от Prometheus, преди да бъдат изтрити.
Когато е активирано, можете да идентифицирате кой клъстер има агенти и кой има наблюдение без агенти.
В сравнение с подхода без агенти, детайлността на вашите данни в графиките ще бъде по-висока с агенти.
Графиките на MySQL
Най-новата версия на ClusterControl 1.7.0 (която можете да изтеглите безплатно - ClusterControl Community) има следните MySQL табла за управление, за които можете да събирате информация за вашите MySQL сървъри. Това са MySQL Overview, MySQL InnoDB Metrics, MySQL Performance Schema и MySQL Replication.
Ще разгледаме подробно графиките, налични в таблото за преглед на MySQL.
Табло за управление с общ преглед на MySQL
Това табло за управление съдържа обичайните важни променливи или информация относно здравето на вашия MySQL възел. Графиките, съдържащи се в това табло за управление, са специфични за възела, избран при преглед на таблата, както се вижда по-долу:
Състои се от 26 графики, но може да не се нуждаете от всички тези, когато диагностицирате проблеми. Въпреки това, тези графики осигуряват жизненоважно представяне на общите показатели за вашите MySQL сървъри. Нека да преминем към основните, тъй като това са може би най-често срещаните неща, които DBA ще разглежда рутинно.
Първите четири графики, показани по-горе, заедно с времето на работа на MySQL, информацията за заявка в секунда и буферния пул са най-основните указатели, от които може да се нуждаем. От графиките, показани по-горе, ето техните представяния:
- MySQL връзки
Това е мястото, където искате да проверите общите си клиентски връзки, разпределени до момента за определен период от време. - Активност на нишките на MySQL
Понякога вашият MySQL сървър може да е много натоварен. Например, може да се очаква да получи скок в трафика в определено време и искате да наблюдавате активността на текущите си нишки. Тази графика е наистина важна за разглеждане. Може да има моменти, когато ефективността на заявката ви може да се понижи, ако например голяма актуализация кара други нишки да чакат, за да придобият заключване. Това ще доведе до увеличаване на броя на текущите ви нишки. Степента на пропуски в кеша се изчислява като Threads_created/Connections. - Въпроси за MySQL
Това са заявките, изпълнявани в определен период от време. Нишката може да е транзакция, съставена от множество заявки и това може да бъде добра графика за разглеждане. - Кеш на нишките на MySQL
Тази графика показва стойността на thread_cache_size, нишките, които се кешират (нишки, които се използват повторно) и нишките, които са създадени (нови нишки). Можете да проверите на тази графика за такива случаи, като например, че трябва да настроите вашите заявки за четене, когато забележите голям брой входящи връзки и създадените ви нишки се увеличават бързо. Например, ако вашият Threads_running / thread_cache_size> 2, тогава увеличаването на вашия thread_cache_size може да повиши производителността на вашия сървър. Обърнете внимание, че създаването и унищожаването на нишки са скъпи. Въпреки това, в последните версии на MySQL (>=5.6.8), тази променлива има автоматично оразмеряване по подразбиране, което може да смятате за недокоснато.
Следващите четири графики са MySQL Temporary Objects, MySQL Select Types, MySQL Sorts и MySQL Slow Queries. Тези графики са свързани помежду си, особено ако диагностицирате продължителни заявки и големи заявки, които се нуждаят от оптимизация.
- Временни обекти на MySQL
Тази графика би била добър източник, на който да разчитате, ако искате да наблюдавате продължително изпълнявани заявки, които в крайна сметка ще използват диск вместо временни таблици или файлове, влизащи в паметта. Това е добро място да започнете да търсите периодична поява на заявки, които могат да доведат до проблеми с дисковото пространство, особено в нечетни моменти. - Избор на MySQL типове
Един източник на лошо представяне са заявки, които използват пълни присъединявания, сканиране на таблици, избор на диапазон, който не използва никакви индекси. Тази графика ще покаже как се представя вашата заявка и какво сред списъка от пълни присъединявания, до присъединяване с пълен диапазон, избор на диапазон, сканиране на таблици има най-високи тенденции. - Сортиране на MySQL
Диагностициране на тези заявки, които използват сортиране, и тези, които отнемат много време за завършване. - Бавни заявки на MySQL
Тенденциите на вашите бавни заявки са събрани тук на тази графика. Това е много полезно, особено за диагностициране на това колко често вашите заявки са бавни. Кои са нещата, които трябва да бъдат настроени? Може да е твърде малък буферен пул, таблици, в които липсват индекси и сканиране на цяла таблица, логически архиви, работещи по неочакван график и т.н. Използването на нашия Query Monitor в ClusterControl заедно с тази графика е полезно, тъй като помага да се определят бавни заявки.
Следващите графики, които имаме, са повече от мрежовата активност, заключванията на таблици и основната вътрешна памет, която MySQL консумира по време на дейността на MySQL.
- MySQL прекратени връзки
Броят на прекъснатите връзки ще се изобрази на тази графика. Това обхваща прекъснатите клиенти, като например, когато мрежата е била затворена внезапно или където интернет връзката е била прекъсната или прекъсната. Той също така записва прекратените свързвания или опити, като грешни пароли или лоши пакети при установяване на връзка от клиента. - Заключване на таблици на MySQL
Тенденции за таблици, които изискват заключване на таблица, което е предоставено незабавно, и за таблици, които изискват заключване, което не е получено незабавно. Например, ако имате заключвания на ниво таблица на MyISAM таблици и входящи заявки на същата таблица, те не могат да бъдат предоставени незабавно. - Мрежов трафик на MySQL
Тази графика показва тенденциите на входящата и изходящата мрежова активност в MySQL сървъра. „Входящи“ са данните, получени от MySQL сървъра, докато „Изходящи“ са данните, изпратени или прехвърлени от сървъра от MySQL сървъра. Тази графика е най-добре да проверите дали искате да наблюдавате мрежовия си трафик, особено когато диагностицирате дали вашият трафик е умерено, но се чудите защо има много висок изходящи прехвърлени данни, като например BLOB данни. - Използване на MySQL мрежа на час
Същото като мрежовия трафик, който показва получените и изпратените данни. Обърнете внимание, че се основава на „на час“ и е обозначен с „последен ден“, което няма да следва периода от време, който сте избрали в инструмента за избор на дата. - Общ преглед на вътрешната памет на MySQL
Тази графика е позната за опитен MySQL DBA. Всяка от тези легенди в лентата е много важна, особено ако искате да наблюдавате използването на паметта си, използването на буферния пул или размера на адаптивния си хеш индекс.
Следните графики показват броячите, на които DBA може да разчита, като например проверка на статистическите данни, статистиката за селектиране, вмъкване, актуализации, броя на главния статус, който е бил изпълнен, броя на SHOW VARIABLES, които са били изпълнени, проверете ако имате лоши заявки, извършващи сканиране на таблици или таблици, които не използват индекси, като преглеждате броячите read_* и т.н.
- Водещи броячи на команди (почасово)
Това са графиките, които вероятно ще трябва да проверявате всеки път, когато искате да видите статистическите данни за вашите вмъквания, изтривания, актуализации, изпълнени команди като събиране на списък с процеси, състояние на подчинено, състояние на показване (статистика за здравето на MySQL сървъра ), и много други. Това е добро място, ако искате да проверите какъв вид броячи на MySQL команди са най-високи и дали е необходима някаква настройка на производителността или оптимизация на заявки. Може също да ви позволи да идентифицирате кои команди се изпълняват агресивно, без да се нуждаят от това. - MySQL манипулатори
Често DBA ще прегледа тези манипулатори и ще провери как се представят заявките във вашия MySQL сървър. По принцип тази графика обхваща броячите от API на Handler на MySQL. Най-често срещаните броячи на манипулатори за DBA за API за съхранение в MySQL са Handler_read_first, Handler_read_key, Handler_read_last, Handler_read_next, Handler_read_prev, Handler_read_rnd и Handler_read_rnd_next. Има много MySQL манипулатори за проверка. Можете да прочетете за тях в документацията тук. - MySQL манипулатори на транзакции
Ако вашият MySQL сървър използва XA транзакции, оператори SAVEPOINT, ROLLBACK TO SAVEPOINT. Тогава тази графика е добра справка за разглеждане. Можете също да използвате тази графика, за да наблюдавате всички вътрешни комитове на вашия сървър. Обърнете внимание, че броячът за Handler_commit се увеличава дори за операторите SELECT, но се различава от операторите за вмъкване/актуализация/изтриване, които отиват в двоичния дневник по време на извикване на оператор COMMIT.
Следващата графика ще покаже тенденции за състоянията на процесите и тяхното почасово използване. Тук в легендата на лентата има много ключови точки, които DBA ще провери. Срещате проблеми с дисковото пространство, проблеми с връзката и вижте дали вашият пул за връзки работи както се очаква, високо ниво на I/O на диска, проблеми с мрежата и т.н.
- Състояния на процеса/Най-добри състояния на процес на час
Тази графика е мястото, където можете да наблюдавате горните състояния на нишките на вашите заявки, изпълнявани в списъка с процеси. Това е много информативно и полезно за такива DBA задачи, където можете да разгледате тук всички неизпълнени състояния, които се нуждаят от разрешаване. Например отваряне на маси състоянието е много високо и минималната му стойност е почти близка до максималната стойност. Това може да означава, че трябва да коригирате table_open_cache. Ако статистическите данни е високо и забелязвате забавяне на вашия сървър, това може да означава, че сървърът ви е свързан с диск и може да се наложи да помислите за увеличаване на вашия буферен пул. Ако имате голям брой създаващи tmp таблица тогава може да се наложи да проверите бавния си дневник и да оптимизирате нарушителните заявки. Можете да проверите ръководството за пълния списък на състоянията на MySQL нишките тук.
Следващата графика, която ще проверяваме, е за кеша на заявките, кеша на дефинициите на MySQL таблицата, колко често MySQL отваря системни файлове.
- Кеш памет/активност на MySQL Query
Тези графики са свързани една с друга. Ако имате query_cache_size <> 0 и query_cache_type <> 0, тогава тази графика може да бъде полезна. Въпреки това, в по-новите версии на MySQL, кешът на заявките е маркиран като остарял, тъй като е известно, че кешът на заявките на MySQL причинява проблеми с производителността. Може да нямате нужда от това в бъдеще. Най-новата версия на MySQL 8.0 има драстични подобрения; има тенденция да повишава производителността, тъй като идва с няколко стратегии за обработка на информацията от кеша в буферите на паметта. - Отвори на MySQL файлове
Тази графика показва тенденцията за отворените файлове от времето на работа на MySQL сървъра, но изключва файлове като сокети или тръби. Той също така не включва файлове, които се отварят от механизма за съхранение, тъй като те имат собствен брояч, който е Innodb_num_open_files. - Отворени файлове на MySQL
Тази графика е мястото, където искате да проверите вашите InnoDB файлове, които в момента са отворени, текущите отворени файлове на MySQL и вашата open_files_limit променлива. - Състояние на отворения кеш на MySQL таблица
Ако тук сте задали много нисък table_open_cache, тази графика ще ви разкаже за онези таблици, които не успяват в кеша (новоотворени таблици) или пропускат поради препълване. Ако срещнете голям брой или твърде много статус „Отварящи се таблици“ във вашия списък с процеси, тази графика ще ви служи като справка, за да определите това. Това ще ви каже дали има нужда да увеличите променливата си table_open_cache. - Отворени таблици на MySQL
В сравнение със състоянието на отворения кеш на MySQL таблицата, тази графика е полезна в определени случаи, като искате да определите дали има нужда да увеличите вашия table_open_cache или да го намалите надолу, ако забележите високо увеличение на отворените таблици или променлива на състоянието на Open_tables . Имайте предвид, че table_open_cache може да заеме голямо количество памет, така че трябва да го настроите внимателно, особено в производствените системи. - Кеш за дефиниции на MySQL таблица
Ако искате да проверите броя на вашите променливи на състоянието Open_table_definitions и Opened_table_definitions, тогава тази графика е това, от което се нуждаете. За по-нови версии на MySQL (>=5.6.8) може да не е необходимо да променяте стойността на тази променлива и да използвате стойността по подразбиране, тъй като има функция за автоматично преоразмеряване.
Заключение
Добавката SCUMM в последната версия на ClusterControl 1.7.0 предоставя значителни нови предимства за редица ключови задачи на DBA. Новите графики могат да помогнат лесно да се определи причината за проблемите, с които обикновено трябва да се справят администраторите на база данни или системните администратори, и да помогнат за по-бързото намиране на подходящи решения.
Ще се радваме да чуем вашия опит и мисли относно използването на ClusterControl 1.7.0 с SCUMM (който можете да изтеглите безплатно - ClusterControl Community).
В част 2 от този блог ще обсъдя ефективно наблюдение на MySQL репликация с табла за управление на SCUMM.
