Веднага щом започнете да стартирате сървър на база данни и използването ви расте, вие сте изложени на много видове технически проблеми, влошаване на производителността и неизправности в базата данни. Всяко от тях може да доведе до много по-големи проблеми, като катастрофална повреда или загуба на данни. Това е като верижна реакция, при която едно нещо може да доведе до друго, причинявайки все повече и повече проблеми. Трябва да се предприемат превантивни мерки за противодействие, за да имате възможно най-дълго стабилна среда.
В тази публикация в блога ще разгледаме куп страхотни функции, предлагани от ClusterControl, които могат значително да ни помогнат да отстраним и поправим проблеми с базата данни MySQL, когато възникнат.
Аларми и известия в базата данни
За всички нежелани събития ClusterControl ще регистрира всичко под Alarms, достъпно в Активност (Горно меню) на страницата ClusterControl. Това обикновено е първата стъпка за започване на отстраняване на неизправности, когато нещо се обърка. От тази страница можем да добием представа какво всъщност се случва с нашия клъстер от база данни:
Горната екранна снимка показва пример за събитие, недостъпно за сървъра, със сериозност КРИТИЧНА , открит от два компонента, мрежа и възел. Ако сте конфигурирали настройката за известия по имейл, трябва да получите копие от тези аларми в пощенската си кутия.
Когато щракнете върху „Пълни подробности за алармата“, можете да получите важните подробности за алармата като име на хост, времева марка, име на клъстер и т.н. Той също така предоставя следващата препоръчителна стъпка, която да предприемете. Можете също да изпратите тази аларма като имейл до други получатели, конфигурирани в настройките за известяване по имейл.
Можете също да изберете да заглушите аларма, като щракнете върху бутона „Игнориране на аларма“ и тя няма да се появи отново в списъка. Игнорирането на аларма може да е полезно, ако имате аларма с ниска тежест и знаете как да се справите или заобиколите нея. Например, ако ClusterControl открие дублиран индекс във вашата база данни, който в някои случаи би бил необходим на вашите наследени приложения.
Като разгледаме тази страница, можем незабавно да разберем какво се случва с нашия клъстер от база данни и каква е следващата стъпка, за да решим проблема. Както в този случай, един от възлите на базата данни се повреди и стана недостъпен чрез SSH от хоста на ClusterControl. Дори начинаещ системен администратор вече би знаел какво да прави след това, ако се появи тази аларма.
Регистрационни файлове на централизирана база данни
Тук можем да разберем какво не е наред с нашия сървър на база данни. Под ClusterControl -> Logs -> System Logs, можете да видите всички регистрационни файлове, свързани с клъстера на базата данни. Що се отнася до базирания на MySQL клъстер от база данни, ClusterControl изтегля дневника на ProxySQL, регистъра на грешките на MySQL и архивните регистри:
Щракнете върху „Обновяване на дневника“, за да извлечете най-новия дневник от всички хостове, които са достъпни в този конкретен момент. Ако възелът е недостижим, ClusterControl все още ще преглежда остарялата регистрация, тъй като тази информация се съхранява в базата данни CMON. По подразбиране ClusterControl продължава да извлича системните регистрационни файлове на всеки 10 минути, конфигурируеми под Settings -> Log Interval.
ClusterControl ще задейства задачата за изтегляне на най-новия дневник от всеки сървър, както е показано в следното задание "Събиране на регистрационни файлове":
Централизираният изглед на регистрационния файл ни позволява по-бързо да разберем какво е станало погрешно. За клъстер от база данни, който обикновено включва множество възли и нива, тази функция значително ще подобри четенето на регистрационни файлове, където SysAdmin може да сравнява тези регистрационни файлове един до друг и да определи критични събития, намалявайки общото време за отстраняване на неизправности.
Уеб SSH конзола
ClusterControl предоставя уеб-базирана SSH конзола, така че да имате достъп до DB сървъра директно чрез потребителския интерфейс на ClusterControl (тъй като SSH потребителят е конфигуриран да се свързва с хостовете на базата данни). От тук можем да съберем много повече информация, която ни позволява да отстраним проблема още по-бързо. Всеки знае, когато проблем с базата данни удари производствената система, всяка секунда престой е от значение.
За достъп до SSH конзолата чрез уеб, просто изберете възлите под Възли -> Действия на възли -> SSH конзола или просто щракнете върху иконата на зъбно колело за пряк път:
Поради опасения за сигурността, които може да бъдат наложени с тази функция, особено за няколко -потребителска или мулти-наемателна среда, можете да я деактивирате, като отидете на /var/www/html/clustercontrol/bootstrap.php на сървъра на ClusterControl и зададете следната константа на false:
define('SSH_ENABLED', false);Опреснете страницата на потребителския интерфейс на ClusterControl, за да заредите новите промени.
Проблеми с производителността на базата данни
Освен функциите за наблюдение и тенденции, ClusterControl ви изпраща проактивно различни аларми и съвети, свързани с производителността на базата данни, например:
- Прекомерно използване – Ресурс, който преминава определени прагове като процесор, памет, използване на суап и дисково пространство.
- Влошаване на клъстера – Клъстер и мрежово разделяне.
- Отклоняване на системното време – Времева разлика между всички възли в клъстера (включително възела ClusterControl).
- Различни други съветници, свързани с MySQL:
- Репликация – забавяне на репликацията, изтичане на binlog, местоположение и растеж
- Galera – SST метод, сканиране на GRA logfile, проверка на адреси на клъстер
- Проверка на схемата – съществуване на таблица без транзакции в Galera Cluster.
- Връзки – съотношение на свързани нишки
- InnoDB – Съотношение на мръсни страници, растеж на регистрационните файлове на InnoDB
- Бавни заявки – По подразбиране ClusterControl ще вдигне аларма, ако открие, че заявка работи за повече от 30 секунди. Това разбира се може да се конфигурира в Настройки -> Конфигурация по време на изпълнение -> Дълга заявка.
- Застой – блокиране на транзакциите в InnoDB и блокиране на Galera.
- Индекси – дублиращи се ключове, таблица без първични ключове.
Разгледайте страницата Съветници под Производителност -> Съветници, за да получите подробности за нещата, които могат да бъдат подобрени, както е предложено от ClusterControl. За всеки съветник той предоставя обосновки и съвети, както е показано в следния пример за съветник „Проверка на използването на дисково пространство“:
Когато възникне проблем с производителността, ще получите "Предупреждение" (жълто) или "Критичен" (червен) статус на тези съветници. Обикновено се изисква допълнителна настройка за преодоляване на проблема. Съветниците повдигат аларми, което означава, че потребителите ще получат копие от тези аларми в пощенската кутия, ако известията по имейл са конфигурирани съответно. За всяка аларма, повдигната от ClusterControl или неговите съветници, потребителите също ще получат имейл, ако алармата е била изчистена. Те са предварително конфигурирани в ClusterControl и не изискват първоначална конфигурация. По-нататъшно персонализиране винаги е възможно под Управление -> Developer Studio. Можете да разгледате тази публикация в блога за това как да напишете свой собствен съветник.
ClusterControl също предоставя специална страница по отношение на производителността на базата данни под ClusterControl -> Performance. Той предоставя всички видове прозрения за база данни, следвайки най-добрите практики като централизиран преглед на състоянието на DB, променливи, състояние на InnoDB, анализатор на схеми, регистрационни файлове на транзакции. Те са доста обясними и лесни за разбиране.
За ефективността на заявката можете да проверите най-популярните заявки и отклоненията на заявките, където ClusterControl откроява заявките, които се изпълняват значително по-различно от средната им заявка. Разгледахме тази тема подробно в тази публикация в блога, настройка на производителността на MySQL Query.
Отчети за грешки в базата данни
ClusterControl се предлага с инструмент за генериране на отчети за грешки, за събиране на информация за отстраняване на грешки за клъстера на базата данни, за да ви помогне да разберете текущата ситуация и състояние. За да генерирате отчет за грешка, просто отидете на ClusterControl -> Регистри -> Доклади за грешки -> Създаване на доклад за грешка:
Генерираният отчет за грешка може да бъде изтеглен от тази страница, след като е готов. Този генериран отчет ще бъде във формат TAR ball (tar.gz) и можете да го прикачите към заявка за поддръжка. Тъй като билетът за поддръжка има ограничението от 10MB за размер на файла, ако размерът на tarball е по-голям от този, можете да го качите в облачно устройство и да споделите с нас връзката за изтегляне само с подходящо разрешение. Можете да го премахнете по-късно, след като вече получим файла. Можете също така да генерирате отчета за грешка чрез команден ред, както е обяснено на страницата с документация за доклад за грешки.
В случай на прекъсване, силно препоръчваме да генерирате множество отчети за грешки по време и веднага след прекъсването. Тези отчети ще бъдат много полезни, за да се опитаме да разберем какво се е объркало, последствията от прекъсването и да проверим дали клъстерът действително е върнат в оперативно състояние след катастрофално събитие.
Заключение
Проактивното наблюдение на ClusterControl, заедно с набор от функции за отстраняване на неизправности, осигуряват ефективна платформа за потребителите за отстраняване на всякакъв вид проблеми с базата данни на MySQL. Отдавна е отминал наследственият начин за отстраняване на неизправности, при който трябва да отворите множество SSH сесии за достъп до множество хостове и да изпълнявате множество команди многократно, за да определите първопричината.
Ако гореспоменатите функции не ви помагат при решаването на проблема или отстраняването на проблема с базата данни, винаги се свържете с екипа за поддръжка на Severalnines, за да ви подкрепи. Нашите 24/7/365 специализирани технически експерти са на разположение да присъстват на вашата заявка по всяко време. Средното ни време за първи отговор обикновено е по-малко от 30 минути.
