Проактивното наблюдение на вашата MySQL база данни е наложително в днешно време. Той играе решаваща и важна роля за управлението и контрола на вашата база данни, особено за вашите клъстери от производствен клас. Липсата на конкретна информация, която би била полезна за подобряване на вашата база данни или неуспехът да се идентифицира основната причина за проблемите, които могат да се срещнат, може да доведе до изключителни трудности за поправяне или възстановяване от дните на слава.
Проактивното наблюдение във вашата MySQL база данни позволява на вашия екип да разбере как се представят услугите ви за бази данни. Функционира ли и доставя ли се въз основа на работното натоварване, което се очаква да носи? Разполагате ли с достатъчно ресурси, за да може сървърът да бъде производителен въз основа на натоварването, което обработва в момента? Проактивното наблюдение прилага неща, които трябва да предотвратят бедствие или да навредят на вашата база данни, което ще ви уведоми предварително. По този начин позволявате на администраторите на база данни или администраторите да изпълняват важни задачи, за да се избегнат неизправности, повреда на данните, експлоати и атаки на сигурността или неочаквано отскачане на трафик във вашия клъстер от база данни. Тъй като те се вземат незабавно, проактивното наблюдение за MySQL трябва да бъде автоматизирано и да работи 24/7 без прекъсване и зависи от DBA, Devops, администраторите да решат дали въз основа на приоритета на задачите и колко е важно, ако изисква поддръжка или просто типична ежедневна рутинна работа.
Проактивно наблюдение с ClusterControl
ClusterControl предлага разнообразен стил за наблюдение на вашите MySQL сървъри на база данни. Подходът му е сравним с други инструменти за корпоративно наблюдение и с облачни решения от корпоративен клас. ClusterControl има тенденция да прилага всички най-добри практики за управление и наблюдение на базите данни, но с гъвкавостта при конфигуриране, за да постигне желаната настройка, базирана във вашата среда.
Когато става въпрос за аларми и известия, ClusterControl има смесен подход, за който има вградени аларми, а след това има съветници, за които ще обсъдим повече в този блог.
Аларми на ClusterControl за MySQL
Алармите показват проблеми, които могат да повлияят или да влошат клъстера като цяло. Този интерфейс предоставя подробно обяснение на проблема, заедно с препоръчителните действия (ако има такива) за разрешаване на проблема. Всяка аларма е категоризирана като:
-
Клъстер
-
Възстановяване на клъстер
-
Състояние на базата данни
-
Ефективност на базата данни
-
Хост
-
Възел
-
Мрежа
Аларма може да бъде потвърдена чрез отметка на Игнориране? квадратче за отметка. Когато се игнорира, няма да се изпраща известие по имейл. Аларма не може да бъде изтрита или отхвърлена, въпреки че можете да я скриете от списъка, като щракнете върху бутона Скриване на игнорирани аларми.
Вижте примерна екранна снимка по-долу,
Проактивност с ClusterControl
ClusterControl поддържа автоматично възстановяване, което реагира при откриване на неизправност. Автоматичното възстановяване с ClusterControl е една от най-проактивните функции, която играе решаваща роля в случай на бедствия.
Активирането на автоматичното възстановяване е необходимо за това проактивно наблюдение, което реагира в различни ситуации, например, ако основният MySQL възел се повреди.
В ClusterControl това ще бъде открито веднага, докато слуша връзката със сървъра на базата данни или в този случай основния сървър. ClusterControl ще реагира възможно най-скоро и ще приложи отказ.
Преминаването при отказ е част от активираното възстановяване на клъстера. Тъй като и двата бутона Cluster и Node са активирани, то следва възстановяването на възела, както виждате по-долу.
В зависимост от достъпността на възлите, ClusterControl ще се опитва непрекъснато да свързване през SSH и се опитайте да стигнете до възела и се опитайте да се възстановите, като започнете да използвате sysvinit или systemd. Очевидно може да си помислите, че прилага отказ и ClusterControl се опитва да стартира неуспешния първичен. Това може да означава, че са налични два възела на базата данни, нали? Въпреки че е вярно, ClusterControl ще преведе неуспешния първичен в състояние само за четене, докато бъде възстановен. Вижте по-долу,
Въпреки че има определени опции, които можете да зададете за управление на механизма за превключване при отказ, вие трябва да се обърнете към нашата документация за това, тъй като това не е фокусът на този блог.
Използване на съветници за проактивност с ClusterControl
В ClusterControl съветниците ще бъдат разположени, като отидете на
Докато е в клъстер на Galera, той добавя специфичните съветници за Galera, както е показано по-долу ,
Персонализиране на вашите ClusterControl MySQL съветници
Съветниците са персонализирани и могат да бъдат модифицирани в съответствие с вашите нужди. В екранната снимка на съветниците по-горе, просто щракнете върху Редактиране и ще бъдете пренасочени към простата IDE, която сме вградили в ClusterControl.
Можете също да създадете свои собствени ClusterControl Advisors. Можете да се обърнете към себе си, за да научите повече за създаването, като прочетете Write Your First Advisor или вземете поредицата от 2 части, за да създадете своя собствена, като използвате скрипт за откриване на Meltdown/Spectre.
Как ClusterControl Advisors са проактивни?
Технически съветниците на ClusterControl действат най-вече като уведомяващи и буквално ваши съветници. ClusterControl Advisors ще ви уведоми, ако открие необичайно поведение, ако достигне базовите прагове, зададени по подразбиране от ClusterControl. Обикновено прилаганите прагове са общи стойности. Тези общи стойности се основават на най-добрите практики и на най-често срещаното и приемливо работно натоварване или настройка на средата. Повечето от съветниците по подразбиране не предоставят аларми или механизми за предупреждение в потребителския интерфейс на ClusterControl. Той ви уведомява чрез потребителския интерфейс (вижте примерна екранна снимка на съветника за местоположението за съхранение на Binlog по-долу).
Както споменахме по-рано, съветниците могат да бъдат модифицирани и редактирани чрез нашия прост редактор или IDE. Например в клъстер за репликация на MySQL, ClusterControl предоставя съветник за местоположение за съхранение на Binlog. Той открива, че binlogs се съхраняват в директорията с данни, където уведомява, че трябва да е извън директорията с данни.
Нека вземем пример от списъка със съветници и изберете Съветник за връзки, използвани в момента . Нека редактираме това, както е показано по-долу,
или като алтернатива можете да преминете към
Като го направите по-проактивен чрез изпращане на аларми, можете да го промените и добавите следните функции, точно както по-долу,
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}Като има предвид, че задаване на прага на 20 след това добавете тези редове по-долу точно в израза за условие if, където прагът е достигнат над дадената прагова стойност.
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
Here's the complete script with my modifications in bold,
#include "common/mysql_helper.js"
var DESCRIPTION="This advisor calculates the percentage of threads_connected over max_connections,"
" if the percentage is higher than 20% you will be notified,"
" preventing your database server from becoming unstable.";
var WARNING_THRESHOLD=20;
var TITLE="Connections currently used";
var ADVICE_WARNING="You are using more than " + WARNING_THRESHOLD +
"% of the max_connections."
" Consider regulating load, e.g by using HAProxy. Using up all connections"
" may render the database server unusable.";
var ADVICE_OK="The percentage of currently used connections is satisfactory." ;
function myAlarm(title, message, recommendation)
{
return Alarm::alarmId(
Node,
true,
title,
message,
recommendation
);
}
function main()
{
var hosts = cluster::mySqlNodes();
var advisorMap = {};
for (idx = 0; idx < hosts.size(); ++idx)
{
host = hosts[idx];
map = host.toMap();
connected = map["connected"];
var advice = new CmonAdvice();
print(" ");
print(host);
print("==========================");
if (!connected)
{
print("Not connected");
continue;
}
var Threads_connected = host.sqlStatusVariable("Threads_connected");
var Max_connections = host.sqlSystemVariable("Max_connections");
if (Threads_connected.isError() || Max_connections.isError())
{
justification = "";
msg = "Not enough data to calculate";
}
else
{
var used = round(100 * Threads_connected / Max_connections,1);
if (used > WARNING_THRESHOLD)
{
advice.setSeverity(1);
msg = ADVICE_WARNING;
justification = used + "% of the connections is currently used,"
" which is > " + WARNING_THRESHOLD + "% of max_connections.";
myAlarmId = myAlarm(TITLE, msg, ADVICE_WARNING);
// Let's raise an alarm.
host.raiseAlarm(myAlarmId, Warning);
}
else
{
justification = used + "% of the connections is currently used,"
" which is < 90% of max_connections.";
advice.setSeverity(0);
msg = ADVICE_OK;
}
}
advice.setHost(host);
advice.setTitle(TITLE);
advice.setJustification(justification);
advice.setAdvice(msg);
advisorMap[idx]= advice;
print(advice.toString("%E"));
}
return advisorMap;
}Можете да използвате sysbench, за да го тествате. В моя тест съм уведомен проактивно чрез изпращане на алармата. Това също ще ми бъде изпратено по имейл или може да бъде уведомено, ако имате интегрирани известия на трети страни. Вижте екранната снимка по-долу,
Предупреждения за съветниците на ClusterControl
Промяната или редактирането на съществуващ съветник в ClusterControl се прилага към всички клъстери. Това означава, че трябва да проверите във вашия скрипт дали има специфично условие, приложимо само за вашия съществуващ клъстер (или MySQL, или други поддържани бази данни от ClusterControl). Това е така, защото ClusterControl съветниците се съхраняват в един източник само чрез нашата cmon DB. Те се изтеглят или извличат от всички клъстери, които сте създали в ClusterControl.
Например, можете да направите това в скрипт:
var hosts =cluster::mySqlNodes();
var advisorMap ={};
print(hosts[1].clusterId());
Този скрипт ще отпечата идентификатора на клъстера. След като получите стойността, присвоете я на променлива и използвайте тази променлива, за да прецените дали е вярно, че този конкретен идентификатор на клъстер е приемлив или не въз основа на желаната от вас задача, която трябва да бъде извършена от вашия съветник. Да кажем,
function main()
{
var hosts = cluster::mySqlNodes();
var advisorMap = {};
for (idx = 0; idx < hosts.size(); ++idx)
{
host = hosts[idx];
map = host.toMap();
connected = map["connected"];
var advice = new CmonAdvice();
print(" ");
print(host);
print("==========================");
if (host.clusterId() == 15)
{
print("Not applicable for cluster id == 15");
continue;
}
…
….
…..което означава, че ако е cluster_id ==15, тогава просто пропуснете или продължете към следващия цикъл.
Заключение
Създаването или модифицирането на ClusterControl Advisors е добра възможност да се възползвате от скритата функционалност, която ClusterControl може да ви предостави. Може да изглежда, че е скрита, но е там - просто функцията се използва по-малко. Той предоставя проста, но мощна функция, наречена ClusterControl Domain Specific Language (CDSL), която може да се използва за изключително трудни задачи, които липсват на ClusterControl. Просто се уверете, че знаете всички предупреждения и също така първо тествайте всичко, преди най-накрая да го приложите към вашата производствена среда.
