Осигуряването на гладка работа на вашите производствени бази данни не е тривиална задача и има редица инструменти и помощни програми, които да ви помогнат с работата. Има налични инструменти за наблюдение на здравето, производителността на сървъра, анализиране на заявки, внедряване, управление на отказ, надстройки и списъкът продължава. ClusterControl като платформа за управление и мониторинг на вашата инфраструктура на базата данни се откроява със способността си да управлява пълния жизнен цикъл от внедряване до наблюдение, текущо управление и мащабиране.
Въпреки че ClusterControl предлага важни функции като автоматично преминаване при отказ на база данни, криптиране при преминаване/в покой, управление на архивиране, възстановяване в момент, интеграция на Prometheus, мащабиране на база данни, те могат да бъдат намерени в други инструменти за управление/мониторинг на предприятието на пазара. Има обаче някои функции, които няма да намерите толкова лесно. В тази публикация в блога ще ви представим 9 функции, които няма да намерите в други инструменти за управление и наблюдение на пазара (като времето на това писане).
Проверка на резервно копие
Всяко архивиране буквално не е резервно копие, докато не разберете, че може да бъде възстановено - като наистина проверите дали може да бъде възстановено. ClusterControl позволява проверка на архивиране, след като бекъпът е направен чрез завъртане на нов сървър и тестване на възстановяване. Проверката на резервно копие е критичен процес, за да сте сигурни, че отговаряте на вашата политика за цел на точката на възстановяване (RPO) в случай на възстановяване при бедствие. Процесът на проверка ще извърши възстановяването на нов самостоятелен хост (където ClusterControl ще инсталира необходимите пакети на база данни преди възстановяване) или на сървър, предназначен за проверка на архивиране.
За да конфигурирате проверка на архивиране, просто изберете съществуващ архив и щракнете върху Възстановяване. Ще има опция за възстановяване и проверка:
След това просто посочете IP адреса на сървъра, който искате да възстановяване и проверка:
Уверете се, че посоченият хост е достъпен чрез SSH без парола предварително. Имате и няколко опции отдолу за процеса на обезпечаване. Можете също да изключите сървъра за проверка след възстановяване, за да спестите разходи и ресурси, след като бекъпът е проверен. ClusterControl ще търси кода за изход от процеса на възстановяване и ще наблюдава регистрационния файл за възстановяване, за да провери дали проверката е неуспешна или успешна.
Опростяване на управлението на ProxySQL чрез GUI
Мнозина биха се съгласили, че наличието на графичен потребителски интерфейс е по-ефективно и по-малко податливо на човешки грешки при конфигуриране на система. ProxySQL е част от критичния слой на базата данни (въпреки че седи върху него) и трябва да бъде достатъчно видим за очите на DBA, за да забележи често срещани проблеми и проблеми. ClusterControl предоставя изчерпателен графичен потребителски интерфейс за ProxySQL.
ProxySQL екземпляри могат да бъдат разгърнати на нови хостове или съществуващите могат да бъдат импортирани в ClusterControl. ClusterControl може да конфигурира ProxySQL да бъде интегриран с виртуален IP адрес (предоставен от Keepalived) за достъп до една крайна точка до сървърите на базата данни. Той също така предоставя информация за наблюдение на ключови компоненти на ProxySQL като Queries Backend, Slow Queries, Top Queries, Query Hits и куп други статистики за наблюдение. Следва екранна снимка, показваща как да добавите ново правило за заявка:
Ако добавяте много сложно правило за заявка, ще ви е по-удобно да го правите чрез графичния потребителски интерфейс. Всяко поле има подсказка, която да ви помогне при попълване на формуляра за правило за заявка. Когато добавя или модифицира конфигурация на ProxySQL, ClusterControl ще се увери, че промените са направени във времето за изпълнение и ще бъдат запазени на диск за постоянство.
ClusterControl 1.7.4 вече поддържа както ProxySQL 1.x, така и ProxySQL 2.x.
Оперативни отчети
Оперативните отчети са набор от обобщени отчети на вашата инфраструктура на базата данни, които могат да се генерират в движение или да бъдат планирани за изпращане до различни получатели. Тези отчети се състоят от различни проверки и се занимават с различни ежедневни задачи на DBA. Идеята зад оперативното отчитане на ClusterControl е да се съберат всички най-подходящи данни в един документ, който може бързо да се анализира, за да се получи ясно разбиране за състоянието на базите данни и нейните процеси.
С ClusterControl можете да планирате отчети за междуклъстерна среда като ежедневен системен отчет, отчет за надграждане на пакета, отчет за промяна на схемата, както и архивиране и наличност. Тези отчети ще ви помогнат да поддържате вашата среда сигурна и работеща. Ще видите и препоръки как да коригирате пропуските. Докладите могат да бъдат адресирани до SysOps, DevOps или дори до мениджъри, които биха искали да получават редовни актуализации на състоянието за състоянието на дадена система.
Следва примерен ежедневен оперативен отчет, изпратен до пощенската ви кутия по отношение на наличността:
Разгледахме това подробно в тази публикация в блога, Преглед на оперативното отчитане на базата данни в ClusterControl.
Повторно синхронизиране на подчинен чрез архивиране
ClusterControl позволява поставяне на подчинен (независимо дали е нов подчинен или повреден подчинен) чрез последното пълно или инкрементално архивиране. Не звучи много вълнуващо, но тази функция е огромна, ако имате големи набори от данни от 100 GB и повече. Обичайната практика при повторно синхронизиране на подчинен е да се предава поточно резервно копие на текущия главен, което ще отнеме известно време в зависимост от размера на базата данни. Това ще добави допълнителна тежест за капитана, което може да застраши работата на капитана.
За да синхронизирате повторно подчинен възел чрез архивиране, изберете подчинения възел под страницата Възли и отидете на Действия на възел -> Възстановяване на подчинено устройство за репликация -> Възстановяване от резервно копие. Само PITR-съвместимо архивиране ще бъде изброено в падащото меню:
Повторното синхронизиране на подчинено устройство от резервно копие няма да донесе допълнителни разходи за главната, където ClusterControl извлича и предава поточно архива от мястото за съхранение на резервно копие в подчинения и евентуално конфигурира връзката за репликация между подчинения към главния. Подчинения по-късно ще настигне главната, след като връзката за репликация бъде установена. Главният елемент е недокоснат по време на целия процес и можете да наблюдавате целия напредък в Активност -> Работни места.
Зареждане на клъстер Galera
Galera Cluster е много популярен при внедряване на висока наличност за MySQL или MariaDB, но грешните команди за управление могат да доведат до катастрофални последици. Разгледайте тази публикация в блога за това как да стартирате клъстер Galera при различни условия. Това илюстрира, че зареждането на Galera Cluster има много променливи и трябва да се извършва с изключително внимание. В противен случай може да загубите данни или да предизвикате разделяне на мозъка. ClusterControl разбира топологията на базата данни и знае точно какво да направи, за да стартира правилно клъстер от база данни. За да стартирате клъстер чрез ClusterControl, щракнете върху Действия на клъстер -> Bootstrap Cluster:
Ще имате опцията да позволите на ClusterControl да избере автоматично правилния начален възел или да извърши първоначално стартиране, при което избирате един от възлите на базата данни от списъка, за да стане референтен възел и да изтриете MySQL datadir на свързващите възли, за да принудите SST от стартиращият възел. Ако процесът на стартиране не успее, ClusterControl ще изтегли дневника за грешки на MySQL.
Ако искате да извършите ръчно стартиране, можете също да използвате функцията „Намиране на най-усъвършенствания възел“ и да извършите операцията за зареждане на клъстера на най-напредналия възел, отчетен от ClusterControl.
Централизирано конфигуриране и регистриране
ClusterControl изтегля редица важни файлове за конфигурация и регистриране и ги показва в дървовидна структура в ClusterControl. Централизираният изглед на тези файлове е от ключово значение за ефективно разбиране и отстраняване на неизправности в настройките на разпределената база данни. Традиционният начин за събиране на тези файлове отдавна е изчезнал с ClusterControl. Следната екранна снимка показва мениджъра на конфигурационните файлове на ClusterControl, който изброява всички свързани конфигурационни файлове за този клъстер в един изглед (с подчертаване на синтаксиса, разбира се):
ClusterControl елиминира повторяемостта при промяна на опция за конфигурация на клъстер от база данни. Промяната на опция за конфигурация на множество възли може да се извърши чрез един интерфейс и съответно ще бъде приложена към възела на базата данни. Когато щракнете върху „Промяна/задаване на параметър“, можете да изберете екземплярите на базата данни, които искате да промените, и да посочите конфигурационната група, параметър и стойност:
Можете да добавите нов параметър в конфигурационния файл или да промените съществуващ параметър . Параметърът ще бъде приложен към времето за изпълнение на избраните възли на базата данни и в конфигурационния файл, ако опцията премине процеса на валидиране на променлива. Някои променливи може да изискват рестартиране на сървъра, което след това ще бъде посъветвано от ClusterControl.
Клониране на клъстер от база данни
С ClusterControl можете бързо да клонирате съществуващ MySQL Galera Cluster, така че да имате точно копие на набора от данни в другия клъстер. ClusterControl извършва операцията по клониране онлайн, без никакво заключване или прекъсване на съществуващия клъстер. Това е като операция за мащабиране на клъстер, освен че и двата клъстера са независими един от друг след приключване на синхронизирането. Клонираният клъстер не е задължително да има същия размер на клъстера като съществуващия. Можем да започнем с „клъстер с един възел“ и да го мащабираме с повече възли на база данни на по-късен етап.
Друга подобна функция, предлагана от ClusterControl, е „Създаване на клъстер от резервно копие“. Тази функция беше въведена в ClusterControl 1.7.1, специално за Galera Cluster и PostgreSQL клъстери, където може да се създаде нов клъстер от съществуващия архив. За разлика от клонирането на клъстер, тази операция не носи допълнително натоварване на изходния клъстер с компромисът, че клонираният клъстер няма да бъде в същото състояние като изходния клъстер.
Разгледахме тази тема подробно в тази публикация в блога, Как да създадете клонинг на вашия MySQL или PostgreSQL клъстер от база данни.
Възстановяване на физическо архивиране
Повечето инструменти за управление на база данни позволяват архивиране на база данни и само шепа от тях поддържат възстановяване на база данни само на логическо архивиране. ClusterControl поддържа пълно възстановяване не само за логически архиви, но и за физически архиви, независимо дали е пълно или инкрементално архивиране. Възстановяването на физическо архивиране изисква редица критични стъпки (особено инкрементални архиви), които основно включват подготовка на архивиране, копиране на подготвените данни в директорията с данни, присвояване на правилно разрешение/собственост и стартиране на възела в правилен ред, за да се поддържа последователност на данните в всички членове на клъстера. ClusterControl изпълнява всички тези операции автоматично.
Можете също да възстановите физическо архивиране на друг възел, който не е част от клъстер. В ClusterControl опцията за това се нарича "Създаване на клъстер от архивиране". Можете да започнете с „клъстер с един възел“, за да тествате процеса на възстановяване на друг сървър или да копирате клъстера на базата данни на друго място.
ClusterControl също така поддържа възстановяване на външно архивно копие, което е направено не чрез ClusterControl. Просто трябва да качите архива на сървъра на ClusterControl и да посочите физическия път до архивния файл при възстановяване. ClusterControl ще се погрижи за останалото.
Репликация от клъстер в клъстер
Това е нова функция, въведена в ClusterControl 1.7.4. ClusterControl вече може да обработва и наблюдава репликацията на клъстер-клъстер, което основно разширява асинхронната репликация на база данни между множество клъстерни набори в множество географски местоположения. Клъстерът може да бъде зададен като главен клъстер (активен клъстер, който обработва четене/записване), а подчинения клъстер може да бъде зададен като клъстер само за четене (клъстер в режим на готовност, който също може да обработва четения). ClusterControl поддържа асинхронна репликация на клъстер-клъстер за Galera Cluster (двоичният дневник трябва да бъде активиран), както и репликация главен-подчинен за поточно репликация на PostgreSQL.
За да създадете нов клъстер, който се копира от друг клъстер, отидете на Действия на клъстер -> Създаване на подчинен клъстер:
Резултатът от горепосоченото внедряване е представен ясно на таблото за управление на списъка с клъстери от база данни :
Подчинения клъстер автоматично се конфигурира като само за четене, репликира се от първичния клъстер и действа като резервен клъстер. Ако бедствие удари основния клъстер и искате да активирате вторичния сайт, просто изберете менюто „Деактивиране само за четене“ , налично в падащото меню Възли -> Действия на възли, за да го популяризирате като активен клъстер.
