MySQL е лесен за инсталиране и използване, винаги е бил популярен сред разработчиците и системните администратори. От друга страна, разгръщането на готова за производство среда MySQL за бизнес-критично работно натоварване на предприятието е различна история. Това може да бъде малко предизвикателство и изисква задълбочени познания за базата данни. В тази публикация в блога ще обсъдим някои от стъпките, които трябва да се предприемат, преди да можем да считаме, че е готово за производство на MySQL внедряване.
Висока наличност
Ако принадлежите към онези късметлии, които могат да приемат часове престой, можете да спрете да четете тук и да преминете към следващия параграф. За 99,999% от критичните за бизнеса системи това не би било приемливо. Следователно разгръщането, готово за производство, трябва да включва мерки за висока наличност. Автоматизираният отказ на екземпляри на базата данни, както и прокси слой, който открива промени в топологията и състоянието на MySQL и съответно насочва трафика, би било основно изискване. Има много инструменти, които могат да се използват за изграждане на такива среди, например MHA, MRM или ClusterControl.
Прокси слой
Главно откриване на неизправност, автоматизирано преминаване при отказ и възстановяване - това са от решаващо значение при изграждането на готова за производство инфраструктура. Но само по себе си това не е достатъчно. Все още има приложение, което ще трябва да се адаптира към промяната на топологията, задействана от отказ. Разбира се, възможно е да се кодира приложението, така че то да е наясно с грешките на екземпляра. Това обаче е тромав и негъвкав начин за обработка на промените в топологията. Тук идва проксито на базата данни - среден слой между приложението и базата данни. Проксито може да скрие сложността на слоя на вашата база данни от приложението - всичко, което приложението прави, е да се свърже с проксито и проксито ще се погрижи за останалото. Проксито ще насочва заявки към екземпляр на база данни, ще обработва промените в топологията и ще пренасочва, ако е необходимо. Прокси може да се използва и за реализиране на разделяне на четене-запис, което освобождава приложението от един по-сложен случай до покриване. Това създава още едно предизвикателство – кой прокси да използвате? Как да го конфигурирам? Как да го наблюдавам? Как да го направим високодостъпен, така че да не се превърне в SPOF?
ClusterControl може да помогне тук. Може да се използва за разполагане на различни прокси сървъри за формиране на прокси слой:ProxySQL, HAProxy и MaxScale. Той предварително конфигурира прокси сървъри, за да се увери, че ще обработват трафика правилно. Освен това улеснява прилагането на всякакви промени в конфигурацията, ако трябва да персонализирате настройката на прокси за вашето приложение. Разделянето на четене и запис може да бъде конфигурирано с помощта на всеки от прокси сървърите, които ClusterControl поддържа. ClusterControl също наблюдава прокси сървърите и ще ги възстанови в случай на неуспехи. Прокси слоят може да се превърне в единствена точка на отказ, тъй като автоматичното възстановяване може да не е достатъчно – за да се справи с това, ClusterControl може да разположи Keepalived и да конфигурира виртуален IP за автоматизиране на отказ.
Резервни копия
Дори и да не е необходимо да прилагате висока наличност, вероятно все пак трябва да се грижите за вашите данни. Архивирането е задължително за почти всяка производствена база данни. Нищо друго освен резервно копие не може да ви спаси от случайно DROP TABLE или DROP SCHEMA (е, може би забавено репликационно подчинено устройство, но само за известен период от време). MySQL предлага множество методи за правене на архиви - mysqldump, xtrabackup, различни типове моментни снимки (някои са налични само при конкретен хардуер или облачен доставчик). Не е лесно да проектирате правилната стратегия за архивиране, да решите кои инструменти да използвате и след това да напишете целия процес, така че да се изпълни правилно. Това също не е ракетна наука и изисква внимателно планиране и тестване. След като направите резервно копие, не сте готови. Сигурни ли сте, че архивът може да бъде възстановен и данните не са боклук? Проверката на вашите архиви отнема много време и може би не е най-вълнуващото нещо, което ще имате в списъка си със задачи. Но все пак е важно и трябва да се прави редовно.
ClusterControl има обширна функционалност за архивиране и възстановяване. Той поддържа mysqldump за логическо архивиране и Percona Xtrabackup за физическо архивиране - тези инструменти могат да се използват в почти всяка среда, облачна или локална. Възможно е да се изгради стратегия за архивиране със смес от логически и физически архиви, постепенни или пълни, по онлайн начин.
Освен възстановяване, той има и опции за проверка на резервно копие - например възстановяването му на отделен хост, за да се провери дали процесът на архивиране работи добре или не.
Ако искате редовно да следите архивирането (и вероятно бихте искали да направите това), ClusterControl има способността да генерира оперативни отчети. Отчетът за архивиране ви помага да проследявате изпълнените архиви и информира дали е имало проблеми, докато ги правите.
Severalnines DevOps Ръководство за управление на бази данни Научете какво трябва да знаете, за да автоматизирате и управлявате своите бази данни с отворен код Изтеглете безплатноМониторинг и тенденция
Нито едно внедряване не е готово за производство без подходящо наблюдение на услугите. Искате да сте сигурни, че ще бъдете предупредени, ако някои услуги станат недостъпни, за да можете да предприемете действие, да разследвате или да започнете процедури за възстановяване. Разбира се, вие също искате да имате актуално решение. Не може да се подчертае достатъчно колко е важно да разполагате с данни от мониторинг за оценка на състоянието на инфраструктурата или за каквото и да е разследване, било то следкланичен или мониторинг в реално време на състоянието на услугите. Показателите не са еднакви по важност - ако не сте много запознати с конкретен продукт от база данни, най-вероятно няма да знаете кои са най-важните показатели, които да събирате и наблюдавате. Разбира се, може да сте в състояние да събирате всичко, но когато става въпрос за преглед на данни, едва ли е възможно да преминете през стотици показатели на хост – трябва да знаете върху кои от тях трябва да се съсредоточите.
Светът с отворен код е пълен с инструменти, предназначени да наблюдават и събират показатели от различни бази данни - повечето от тях ще изискват от вас да ги интегрирате с цялостната си инфраструктура за наблюдение, платформа за чатове или инструменти за поддръжка на повикване (като PagerDuty). Може също да се наложи да инсталирате и интегрирате множество компоненти – съхранение (някакъв вид база данни от времеви серии), слой за представяне и инструменти за събиране на данни.
ClusterControl е малко по-различен подход, тъй като е един единствен продукт с наблюдение в реално време, тенденции и табла за управление, които показват най-важните детайли. Съветниците за бази данни, които могат да бъдат всякакви, от прости съвети за конфигуриране, предупреждения за прагове или по-сложни правила за прогнози, обикновено ще дадат изчерпателни препоръки.
Възможност за мащабиране
Базите данни имат тенденция да нарастват по размер и не е малко вероятно той да нарасне по отношение на обема на транзакциите или броя на потребителите. Възможността за мащабиране или увеличаване може да бъде от решаващо значение за производството. Дори ако свършите страхотна работа при оценката на вашите хардуерни изисквания в началото на жизнения цикъл на продукта, вероятно ще трябва да се справите с фаза на растеж - стига продуктът ви да е успешен (но това е, което всички ние планираме, нали ?). Трябва да разполагате със средствата за лесно разширяване на вашата инфраструктура, за да се справите с входящия товар. За услуги без състояние, като уеб сървъри, това е доста лесно - просто трябва да предоставите повече екземпляри, като използвате най-новото производствено изображение или код от вашия инструмент за контрол на версиите. За услуги със състояние, като бази данни, това е по-трудно. Трябва да предоставите нови екземпляри, като използвате текущите си производствени данни, да настроите репликация или някаква форма на клъстериране между текущите и новите екземпляри. Това може да бъде сложен процес и за да го направите правилно, трябва да имате по-задълбочени познания за избрания модел за клъстериране или репликация.
ClusterControl, както подсказва името, предоставя обширна поддръжка за изграждане на клъстерни или репликирани настройки на база данни. Използваните методи са тествани в битка чрез хиляди разгръщания. Той идва с интерфейс на командния ред (CLI), така че може лесно да бъде интегриран със системи за управление на конфигурацията. Моля, имайте предвид обаче, че може да не искате да правите промени в своя пул от бази данни твърде често - осигуряването на нов екземпляр отнема време и добавя някои допълнителни разходи в съществуващите бази данни. Ето защо може да искате да останете малко на „свръхосигурена“ страна, за да имате известно време да завъртите нов екземпляр, преди вашият клъстер да се претовари.
Като цяло има няколко стъпки, които все още трябва да предприемете след първоначалното внедряване, за да сте сигурни, че вашата среда е готова за производство. С правилните инструменти е много по-лесно да стигнете до там.
