По-голямата част от DBA извършват здравни проверки на своите бази данни от време на време. Обикновено това се случва на дневна или седмична база. По-рано обсъдихме защо такива проверки са важни и какво трябва да включват.
За да се уверите, че вашите системи са в добро състояние, ще трябва да преминете през доста много информация - статистика на хоста, статистика на MySQL, статистика на работното натоварване, състояние на архивиране, пакети на база данни, регистрационни файлове и така нататък. Такива данни трябва да са налични във всяка правилно наблюдавана среда, въпреки че понякога са разпръснати на множество места - може да имате един инструмент за наблюдение на състоянието на MySQL, друг инструмент за събиране на системна статистика, може би набор от скриптове, например за проверка на състоянието на вашите резервни копия. Това прави здравните проверки много по-отнемащи време, отколкото би трябвало – DBA трябва да събере различните части, за да разбере състоянието на системата.
Интегрираните инструменти като ClusterControl имат предимство, че всички битове са разположени на едно и също място (или в едно и също приложение). Това все още не означава, че са разположени един до друг – може да са разположени в различни секции на потребителския интерфейс и DBA може да трябва да прекара известно време в щракване върху потребителския интерфейс, за да достигне до всички интересни данни.
Цялата идея зад създаването на оперативни отчети е да поставите всички най-важни данни в един документ, който може бързо да се прегледа, за да се разбере състоянието на базите данни.
Оперативните отчети са достъпни от менюто Странично меню -> Оперативни отчети:
След като отидете там, ще ви бъде представен списък с отчети, създадени ръчно или автоматично, въз основа на предварително дефиниран график:
Ако искате да създадете нов отчет ръчно, ще използвате опцията „Създаване“. Изберете типа на отчета, името на клъстера (за отчет за всеки клъстер), получателите на имейл (по избор - ако искате отчетът да ви бъде доставен) и сте почти готови:
Отчетите също могат да бъдат планирани да се създават редовно:
Понастоящем са налични 5 типа отчети:
- Отчет за наличността – Всички клъстери.
- Отчет за архивиране – Всички клъстери.
- Отчет за промяна на схемата – само клъстер, базиран на MySQL/MariaDB.
- Ежедневен системен отчет – на клъстер.
- Отчет за надграждане на пакета – на клъстер.
Отчет за наличност
Отчетите за наличност се фокусират върху наличността. Включва три раздела. Първо, обобщение на наличността:
Можете да видите информация за статистическите данни за наличността на вашите бази данни, типа на клъстера, общото време на работа и престой, текущото състояние на клъстера и кога последното се е променило.
Друг раздел дава повече подробности за наличността за всеки клъстер. Екранната снимка по-долу показва само един от клъстерите на базата данни:
Можем да видим кога даден възел е превключил състояние и какъв е бил преходът. Това е хубаво място да проверите дали е имало скорошни проблеми с клъстера. Подобни данни са показани в третия раздел на този отчет, където можете да прегледате историята на промените в състоянието на клъстера.
Отчет за архивиране
Вторият тип отчет е такъв, който обхваща архивиране на всички клъстери. Той съдържа два раздела - резюме на архивиране и подробности за архивиране, където първият основно ви дава кратко обобщение за това кога е създадено последното архивиране, дали е завършено успешно или неуспешно, състояние на проверка на архивиране, процент на успех и период на запазване:
ClusterControl също така предоставя примери за политика за архивиране, ако открие, че някой от наблюдаваните клъстери на база данни работи без да е конфигурирано планирано архивиране или отложено подчинено устройство. Следват подробностите за архивирането:
Можете също да проверите списъка с архиви, изпълнявани в клъстера с тяхното състояние, тип и размер в рамките на посочения интервал. Това е възможно най-близо, за да сте сигурни, че архивите работят правилно, без да провеждате пълен тест за възстановяване. Определено препоръчваме подобни тестове да се правят от време на време. Добрата новина е, че ClusterControl поддържа базирано на MySQL възстановяване и проверка на самостоятелен хост под Backup -> Restore Backup.
Ежедневен системен отчет
Този тип отчет съдържа подробна информация за конкретен клъстер. Започва с обобщение на различни сигнали, които са свързани с клъстера:
Следващият раздел е за състоянието на възлите, които са част от клъстера:
Имате списък с възлите в клъстера, техния тип, роля (главен или подчинен), състояние на възела, време на работа и ОС.
Друг раздел от отчета е резюмето за архивиране, същото, което обсъдихме по-горе. Следващата представя обобщение на най-популярните заявки в клъстера:
И накрая, виждаме „Преглед на състоянието на възела“, в който ще ви бъдат представени графики, свързани с показатели за OS и MySQL за всеки възел.
Както можете да видите, тук имаме графики, покриващи всички аспекти на натоварването на хоста - процесор, памет, мрежа, диск, натоварване на процесора и свободен диск. Това е достатъчно, за да добиете представа дали нещо странно се е случило наскоро или не. Можете също така да видите някои подробности за натоварването на MySQL - колко заявки са били изпълнени, кой тип заявка, как е осъществен достъп до данните (чрез кой манипулатор)? Това, от друга страна, трябва да е достатъчно, за да изберете повечето от проблемите от страна на MySQL. Това, което искате да разгледате, са всички пикове и спадове, които не сте виждали в миналото. Може би към микса е добавена нова заявка и в резултат на това handler_read_rnd_next скочи до небето? Може би има увеличение на натоварването на процесора и голям брой връзки може да сочат за повишено натоварване на MySQL, но също и до някакъв вид спор. Може да е добре да се проучи неочакван модел, за да знаете какво се случва.
Отчет за надграждане на пакета
Този отчет дава обобщение на пакетите, налични за надграждане от мениджъра на хранилището на наблюдаваните хостове. За точно отчитане се уверете, че винаги използвате стабилни и надеждни хранилища на всеки хост. В някои нежелани случаи наблюдаваните хостове могат да бъдат конфигурирани с остаряло хранилище след надстройка (например всяка основна версия на MariaDB използва различно хранилище), непълно вътрешно хранилище (например частично огледално от нагоре по веригата) или хранилище с изтекъл край (обикновено за нестабилни пакети за нощно изграждане).
Първият раздел е резюмето на надстройката:
Той обобщава общия брой пакети, налични за надграждане, както и свързаната управлявана услуга за клъстера като балансьор на натоварване, виртуален IP адрес и арбитър. След това ClusterControl предоставя подробен списък с пакети, групиран по тип пакет за всеки хост:
Този отчет предоставя наличната версия и може значително да ни помогне да планираме ефективно нашия прозорец за поддръжка. За критични надстройки, като пакети за сигурност и бази данни, бихме могли да го приоритизираме пред некритични надстройки, които биха могли да бъдат консолидирани с други прозорци за поддръжка с по-малък приоритет.
Отчет за промяна на схемата
Този отчет сравнява избраните промени в базата данни на MySQL/MariaDB в структурата на таблицата, които са се случили между два различни генерирани отчета. В по-старите версии на MySQL/MariaDB DDL операцията е неатомарна операция (преди 8.0) и изисква пълно копие на таблицата (преди 5.6 за повечето операции) – блокиране на други транзакции, докато завърши. Промените в схемата могат да се превърнат в огромна болка, след като вашите таблици получат значително количество данни и трябва да бъдат внимателно планирани, особено в клъстерна настройка. В многостепенна среда за разработка сме виждали много случаи, когато разработчиците безшумно променят структурата на таблицата, което води до значително въздействие върху производителността на заявките.
За да може ClusterControl да изготви точен отчет, специални опции трябва да бъдат конфигурирани в CMON конфигурационния файл за съответния клъстер:
- schema_change_detection_address - Проверките ще бъдат извършени с помощта на ПОКАЖЕТЕ ТАБЛИЦИТЕ/ПОКАЖЕТЕ СЪЗДАВАНЕ НА ТАБЛИЦА, за да се определи дали схемата се е променила. Проверките се изпълняват на посочения адрес и са във формат HOSTNAME:PORT. schema_change_detection_databases също трябва да се настрои. Създава се диференциал на променена таблица (с помощта на diff).
- schema_change_detection_databases - Разделен със запетая списък с бази данни за наблюдение за промени в схемата. Ако е празен, не се правят проверки.
В този пример бихме искали да наблюдаваме промените в схемата за база данни „myapp“ и „sbtest“ в нашия MariaDB клъстер с идентификатор на клъстер 27. Изберете един от възлите на базата данни като стойност на schema_change_detection_address . За MySQL репликация, това трябва да бъде главният хост или всеки подчинен хост, който държи базите данни (в случай, че частичната репликация е активна). След това в /etc/cmon.d/cmon_27.cnf добавете следните два реда:
schema_change_detection_address=10.0.0.30:3306
schema_change_detection_databases=myapp,sbtestРестартирайте услугата CMON, за да заредите промяната:
$ systemctl restart cmonЗа първия и основен отчет ClusterControl връща само резултата от събирането на метаданни, подобно на по-долу:
С първия отчет като базова линия, следващите отчети ще върнат резултата, който очакваме за:
Обърнете внимание, че в отчета се отпечатват само нови или променени таблици. Първият отчет е само за събиране на метаданни за сравнение в следващите кръгове, така че трябва да го стартираме поне два пъти, за да видим разликата.
С този отчет вече можете да събирате отпечатъците на структурата на базата данни и да разберете как вашата база данни се е развивала във времето.
Последни мисли
Оперативният отчет е изчерпателен начин да разберете състоянието на инфраструктурата на вашата база данни. Той е създаден както за оперативен, така и за управленски персонал и може да бъде много полезен при анализиране на операциите на вашата база данни. Отчетите могат да се генерират на място или да ви се доставят по имейл, което прави нещата удобно лесни, ако имате силоз за отчитане.
Ще се радваме да чуем отзивите ви за всичко друго, което искате да включите в отчета, какво липсва и какво не е необходимо.
