MySQL в облака - плюсове и минуси на Amazon RDS

Преместването на вашите данни в публична облачна услуга е голямо решение. Всички основни доставчици на облачни услуги предлагат облачни услуги за бази данни, като Amazon RDS за MySQL е може би най-популярният.

В този блог ще разгледаме отблизо какво представлява, как работи и ще сравним плюсовете и минусите му.

RDS (Услуга за релационна база данни) е предложение за уеб услуги на Amazon. Накратко, това е база данни като услуга, където Amazon разгръща и управлява вашата база данни. Той се грижи за задачи като архивиране и корекция на софтуера на базата данни, както и за висока наличност. Няколко бази данни се поддържат от RDS, но ние се интересуваме главно от MySQL - Amazon поддържа MySQL и MariaDB. Има и Aurora, която е клонинг на MySQL на Amazon, подобрен, особено в областта на репликация и висока наличност.

Разгръщане на MySQL чрез RDS

Нека да разгледаме внедряването на MySQL чрез RDS. Избрахме MySQL и след това ни се представят няколко модела на внедряване, от които да избираме.

Основният избор е – искаме ли да имаме висока наличност или не? Аврора също е популяризирана.

Следващият диалогов прозорец ни дава някои опции за персонализиране. Можете да изберете една от многото версии на MySQL - налични са няколко версии 5.5, 5.6 и 5.7. Екземпляр на база данни – можете да избирате от типичните размери на екземпляра, налични в даден регион.

Следващата опция е доста важен избор - искате ли да използвате внедряване с няколко AZ или не? Всичко това е свързано с висока наличност. Ако не искате да използвате внедряване с няколко AZ, ще бъде инсталиран един екземпляр. В случай на повреда, нов ще бъде създаден и неговият обем от данни ще бъде повторно монтиран към него. Този процес отнема известно време, през което вашата база данни няма да бъде налична. Разбира се, можете да сведете до минимум това въздействие, като използвате подчинени устройства и популяризирате един от тях, но това не е автоматизиран процес. Ако искате да имате автоматизирана висока наличност, трябва да използвате внедряване с няколко AZ. Това, което ще се случи е, че ще бъдат създадени две копия на база данни. Единият ви се вижда. Вторият екземпляр, в отделна зона за наличност, не се вижда от потребителя. Той ще действа като копие в сянка, готово да поеме трафика, след като активният възел се повреди. Това все още не е идеално решение, тъй като трафикът трябва да се превключи от неуспешния екземпляр към този в сянка. В нашите тестове бяха необходими ~45 секунди за извършване на отказ, но очевидно това може да зависи от размера на инстанцията, I/O производителността и т.н. Но е много по-добре от неавтоматизираното преминаване на отказ, където участват само подчинени.

И накрая, имаме настройки за съхранение – тип, размер, PIOPS (където е приложимо) и настройки на базата данни – идентификатор, потребител и парола.

В следващата стъпка още няколко опции чакат въвеждането на потребителя.

Можем да изберем къде да бъде създаден екземплярът:VPC, подмрежа, дали да е публично достъпен или не (както - трябва ли публичен IP да бъде присвоен на RDS инстанцията), зона за достъпност и VPC Security Group. След това имаме опции за база данни:първата схема, която трябва да бъде създадена, портове, групи параметри и опции, дали маркерите за метаданни трябва да бъдат включени в моментните снимки или не, настройки за криптиране.

На следващо място, опции за архивиране – колко дълго искате да съхранявате резервните си копия? Кога бихте искали да ги вземат? Подобна настройка е свързана с поддръжката - понякога администраторите на Amazon трябва да извършват поддръжка на вашия RDS екземпляр - това ще се случи в рамките на предварително дефиниран прозорец, който можете да зададете тук. Моля, имайте предвид, че няма опция да не изберете поне 30 минути за прозореца за поддръжка, ето защо наличието на мулти-AZ инстанция в производството е наистина важно. Поддръжката може да доведе до рестартиране на възел или липса на наличност за известно време. Без няколко AZ, трябва да приемете това време на престой. При внедряване с няколко AZ се извършва преодоляване на срив.

И накрая, имаме настройки, свързани с допълнителен мониторинг – искаме ли да го активираме или не?

Управление на RDS

В тази глава ще разгледаме по-отблизо как да управлявате MySQL RDS. Няма да разглеждаме всички налични опции, но бихме искали да подчертаем някои от функциите, предоставени от Amazon.

Моментни снимки

MySQL RDS използва EBS томове като съхранение, така че може да използва EBS моментни снимки за различни цели. Архивни копия, подчинени - всичко базирано на моментни снимки. Можете да създавате моментни снимки ръчно или да се правят автоматично, когато възникне такава нужда. Важно е да се има предвид, че EBS моментните снимки като цяло (не само на RDS екземпляри) добавят някои допълнителни разходи към I/O операциите. Ако искате да направите моментна снимка, очаквайте вашата I/O производителност да спадне. Освен ако не използвате внедряване с няколко AZ, т.е. В такъв случай „сенчестият“ екземпляр ще се използва като източник на моментни снимки и няма да бъде видимо въздействие върху производствения екземпляр.

Резервни копия

Архивите се базират на моментни снимки. Както бе споменато по-горе, можете да дефинирате своя график за архивиране и задържане, когато създавате нов екземпляр. Разбира се, можете да редактирате тези настройки след това чрез опцията „промяна на екземпляра“.

По всяко време можете да възстановите моментна снимка - трябва да отидете в секцията за моментна снимка, да изберете моментната снимка, която искате да възстановите, и ще ви бъде представен диалогов прозорец, подобен на този, който сте виждали, когато сте създали нов екземпляр. Това не е изненада, тъй като можете да възстановите само моментна снимка в нов екземпляр - няма начин да го възстановите в един от съществуващите RDS екземпляри. Може да е изненада, но дори в облачна среда може да има смисъл да използвате повторно хардуер (и екземпляри, които вече имате). В споделена среда производителността на един виртуален екземпляр може да се различава - може да предпочетете да се придържате към профила на производителност, с който вече сте запознати. За съжаление, това не е възможно в RDS.

Друга възможност в RDS е възстановяването в момента - много важна функция, изискване за всеки, който трябва да се грижи добре за своите данни. Тук нещата са по-сложни и не толкова ярки. Като за начало е важно да имате предвид, че MySQL RDS крие двоични регистрационни файлове от потребителя. Можете да промените няколко настройки и да изброите създадените binlogs, но нямате директен достъп до тях - за да извършите каквато и да е операция, включително използването им за възстановяване, можете да използвате само потребителския интерфейс или CLI. Това ограничава вашите опции до това, което Amazon ви позволява да правите, и ви позволява да възстановите архива си до най-новото „възстановяемо време“, което се изчислява на интервал от 5 минути. Така че, ако вашите данни са били премахнати в 9:33a, можете да ги възстановите само до състоянието в 9:30a. Възстановяването в даден момент работи по същия начин като възстановяването на моментни снимки – създава се нов екземпляр.

Мащабиране, репликация

MySQL RDS позволява мащабиране чрез добавяне на нови подчинени устройства. Когато се създаде подчинен, се прави моментна снимка на главния и се използва за създаване на нов хост. Тази част работи доста добре. За съжаление не можете да създадете по-сложна топология на репликация като тази, включваща междинни главни. Не можете да създадете главна - главна настройка, която оставя всяка HA в ръцете на Amazon (и внедряване с няколко AZ). От това, което можем да кажем, няма начин да активирате GTID (не че бихте могли да се възползвате от него, тъй като нямате никакъв контрол върху репликацията, няма CHANGE MASTER в RDS), само обикновени, старомодни позиции на binlog.

Липсата на GTID прави невъзможно използването на многонишкова репликация - въпреки че е възможно да се настроят определен брой работници, използващи RDS групи параметри, без GTID това е неизползваемо. Основният проблем е, че няма начин да се локализира единична двоична регистрационна позиция в случай на катастрофа - някои работници може да са били назад, някои може да са по-напреднали. Ако използвате последното приложено събитие, ще загубите данни, които все още не са приложени от тези „изоставащи“ работници. Ако използвате най-старото събитие, най-вероятно ще получите грешки с „дублиран ключ“, причинени от събития, приложени от онези работници, които са по-напреднали. Разбира се, има начин за решаване на този проблем, но той не е тривиален и отнема много време – определено не е нещо, което лесно можете да автоматизирате.

Потребителите, създадени на MySQL RDS, нямат СУПЕР привилегия, така че операциите, които са прости в самостоятелен MySQL, не са тривиални в RDS. Amazon реши да използва съхранени процедури, за да даде възможност на потребителя да извърши някои от тези операции. От това, което можем да кажем, са обхванати редица потенциални проблеми, въпреки че не винаги е било така - помним, когато не можете да завъртите към следващия двоичен регистрационен файл на главния. Главен срив + повреда на binlog може да доведе до повреда на всички подчинени устройства - сега има процедура за това:rds_next_master_log .

Подчинен може да бъде ръчно повишен в главен. Това би ви позволило да създадете някакъв вид HA върху механизма с множество AZ (или заобикаляйки го), но това е безсмислено от факта, че не можете да преподавате нито един от съществуващите подчинени устройства на новия главен. Не забравяйте, че нямате никакъв контрол върху репликацията. Това прави цялото упражнение безполезно - освен ако вашият господар не може да побере целия ви трафик. След като повишите нов главен, не можете да преминете към него, защото той няма подчинени устройства, които да се справят с вашия товар. Завъртането на нови подчинени устройства ще отнеме време, тъй като EBS моментните снимки трябва да бъдат създадени първо и това може да отнеме часове. След това трябва да затоплите инфраструктурата, преди да можете да я натоварите.

Липса на СУПЕР привилегия

Както казахме по-рано, RDS не предоставя на потребителите SUPER привилегия и това става досадно за някой, който е свикнал да го има в MySQL. Приемете за даденост, че през първите седмици ще научите колко често се изисква да правите неща, които правите доста често – като унищожаване на заявки или работа със схемата за изпълнение. В RDS ще трябва да се придържате към предварително дефиниран списък със съхранени процедури и да ги използвате, вместо да правите нещата директно. Можете да изброите всички от тях, като използвате следната заявка:

SELECT specific_name FROM information_schema.routines;

Както при репликацията, редица задачи са обхванати, но ако се окажете в ситуация, която все още не е покрита, тогава нямате късмет.

Интероперативна съвместимост и настройки на хибриден облак

Това е друга област, в която на RDS липсва гъвкавост. Да речем, че искате да изградите смесена облачна/локална настройка - имате RDS инфраструктура и бихте искали да създадете няколко подчинени локални устройства. Основният проблем, с който ще се сблъскате, е, че няма начин да преместите данни извън RDS, освен да вземете логически дъмп. Можете да правите моментни снимки на RDS данни, но нямате достъп до тях и не можете да ги преместите далеч от AWS. Освен това нямате физически достъп до екземпляра, за да използвате xtrabackup, rsync или дори cp. Единствената възможност за вас е да използвате mysqldump, mydumper или подобни инструменти. Това добавя сложност (наборът от знаци и настройките за съпоставяне могат да причинят проблеми) и отнема много време (отнема много време за изхвърляне и зареждане на данни с помощта на логически инструменти за архивиране).

Възможно е да се настрои репликация между RDS и външен екземпляр (и по двата начина, така че мигрирането на данни в RDS също е възможно), но това може да бъде много отнемащ време процес.

От друга страна, ако искате да останете в RDS среда и да обхванете инфраструктурата си през Атлантическия океан или от източното до западното крайбрежие на САЩ, RDS ви позволява да направите това - можете лесно да изберете регион, когато създадете нов подчинен.

За съжаление, ако искате да преместите своя главен обект от един регион в другия, това на практика не е възможно без прекъсване – освен ако единичният ви възел не може да се справи с целия ви трафик.

Сигурност

Докато MySQL RDS е управлявана услуга, не всеки аспект, свързан със сигурността, се поема от инженерите на Amazon. Amazon го нарича „модел на споделена отговорност“. Накратко, Amazon се грижи за сигурността на мрежата и слоя за съхранение (така че данните да се прехвърлят по сигурен начин), операционната система (пачове, корекции на сигурността). От друга страна, потребителят трябва да се погрижи за останалата част от модела за сигурност. Уверете се, че трафикът към и от RDS екземпляр е ограничен в рамките на VPC, уверете се, че удостоверяването на ниво база данни е извършено правилно (няма потребителски акаунти на MySQL без парола), проверете дали сигурността на API е осигурена (AMI са зададени правилно и с минимални необходими привилегии). Потребителят трябва също да се погрижи за настройките на защитната стена (групи за сигурност), за да сведе до минимум излагането на RDS и VPC, в които се намира, към външни мрежи. Отговорност на потребителя е също така да внедри криптиране на данни в покой - на ниво приложение или на ниво база данни, като на първо място създаде криптиран екземпляр на RDS.

Шифроването на ниво база данни може да бъде активирано само при създаването на екземпляр, не можете да шифровате съществуваща, вече работеща база данни.

Ограничения на RDS

Ако планирате да използвате RDS или ако вече го използвате, трябва да сте наясно с ограниченията, които идват с MySQL RDS.

Липса на СУПЕР привилегия може да бъде, както споменахме, много досадно. Докато съхранените процедури се грижат за редица операции, това е крива на обучение, тъй като трябва да се научите да правите нещата по различен начин. Липсата на SUPER привилегия също може да създаде проблеми при използването на външни инструменти за наблюдение и тенденции – все още има някои инструменти, които може да изискват това привилегия за част от своята функционалност.

Липсата на директен достъп до директорията с данни и регистрационните файлове на MySQL прави по-трудно извършването на действия което ги включва. От време на време се случва, че DBA трябва да анализира двоични регистрационни файлове или грешка в опашката, бавна заявка или общ дневник. Въпреки че е възможно да получите достъп до тези регистрационни файлове на RDS, това е по-тромаво, отколкото да правите каквото ви трябва, като влезете в shell на хоста на MySQL. Изтеглянето им локално също отнема известно време и добавя допълнителна латентност към всичко, което правите.

Липса на контрол върху топологията на репликация, висока наличност само при внедряване с няколко AZ. Като се има предвид, че нямате контрол върху репликацията, не можете да внедрите какъвто и да е механизъм за висока наличност в слоя на вашата база данни. Няма значение, че имате няколко подчинени устройства, не можете да използвате някои от тях като кандидати за главен, защото дори и да повишите роб в господар, няма начин да преработите останалите робове от този нов господар. Това принуждава потребителите да използват внедряване на няколко AZ и да увеличават разходите („сенчестият“ екземпляр не е безплатен, потребителят трябва да плати за него).

Намалена наличност поради планиран престой. Когато разгръщате RDS екземпляр, вие сте принудени да изберете седмичен времеви прозорец от 30 минути, през който операциите по поддръжката могат да се изпълняват на вашия RDS екземпляр. От една страна, това е разбираемо, тъй като RDS е база данни като услуга, така че хардуерните и софтуерните надстройки на вашите RDS екземпляри се управляват от инженерите на AWS. От друга страна, това намалява наличността ви, тъй като не можете да предотвратите падането на основната ви база данни по време на периода на поддръжка. Отново, в този случай използването на настройка за няколко AZ увеличава наличността, тъй като промените се случват първо в сенчестия екземпляр и след това се изпълнява отказоустойчивост. Самото отказване обаче не е прозрачно, така че, по един или друг начин, губите време за работа. Това ви принуждава да проектирате приложението си, като имате предвид неочаквани грешки в MySQL master. Не че това е лош модел на проектиране - базите данни могат да се сринат по всяко време и приложението ви трябва да бъде изградено по начин, по който може да издържи дори на най-тежкия сценарий. Просто с RDS имате ограничени възможности за висока наличност.

Намалени опции за внедряване с висока наличност. Като се има предвид липсата на гъвкавост в управлението на топологията на репликация, единственият възможен метод за висока наличност е разполагането с множество AZ. Този метод е добър, но има инструменти за репликация на MySQL, които биха свели до минимум времето за престой още повече. Например, MHA или ClusterControl, когато се използват във връзка с ProxySQL, могат да доставят (при някои условия като липса на продължителни транзакции) прозрачен процес на отказ за приложението. Докато сте на RDS, няма да можете да използвате този метод.

Намалена информация за ефективността на вашата база данни. Въпреки че можете да получите показатели от самия MySQL, понякога това просто не е достатъчно, за да получите пълен изглед от 10 000 фута на ситуацията. В даден момент по-голямата част от потребителите ще трябва да се справят с наистина странни проблеми, причинени от дефектен хардуер или дефектна инфраструктура - загубени мрежови пакети, внезапно прекратени връзки или неочаквано високо използване на процесора. Когато имате достъп до вашия MySQL хост, можете да използвате много инструменти, които ви помагат да диагностицирате състоянието на Linux сървър. Когато използвате RDS, вие сте ограничени до какви показатели са налични в Cloudwatch, инструмента за наблюдение и тенденции на Amazon. Всяка по-подробна диагностика изисква да се свържете с поддръжката и да ги помолите да проверят и отстранят проблема. Това може да е бързо, но също така може да бъде много дълъг процес с много комуникация по имейл.

Заключване на доставчика, причинено от сложен и отнемащ време процес на извличане на данни от MySQL RDS. RDS не предоставя достъп до директорията с данни на MySQL, така че няма начин да се използват стандартни инструменти като xtrabackup за преместване на данни по двоичен начин. От друга страна, RDS под капака е MySQL, поддържан от Amazon, трудно е да се каже дали е 100% съвместим с upstream или не. RDS е наличен само в AWS, така че няма да можете да направите хибридна настройка.

Резюме

MySQL RDS има както силни, така и слаби страни. Това е много добър инструмент за тези, които искат да се съсредоточат върху приложението, без да се притесняват за работа с базата данни. Разгръщате база данни и започвате да издавате заявки. Няма нужда от създаване на скриптове за архивиране или настройка на решение за наблюдение, защото вече е направено от инженери на AWS - всичко, което трябва да направите, е да го използвате.

Има и тъмна страна на MySQL RDS. Липса на опции за изграждане на по-сложни настройки и мащабиране извън просто добавяне на повече подчинени устройства. Липса на поддръжка за по-добра висока наличност от това, което се предлага при внедряване с няколко AZ. Тежък достъп до регистрационните файлове на MySQL. Липса на директен достъп до директорията с данни на MySQL и липса на поддръжка за физически архиви, което затруднява преместването на данните извън екземпляра на RDS.

За да обобщим, RDS може да работи добре за вас, ако цените лекотата на използване пред подробния контрол на базата данни. Трябва да имате предвид, че в някакъв момент в бъдеще може да надраснете MySQL RDS. Тук не говорим непременно само за производителност. Става дума повече за нуждите на вашата организация от по-сложна топология на репликация или нужда от по-добра представа за операциите на базата данни, за да се справите бързо с различни проблеми, които възникват от време на време. В този случай, ако вашият набор от данни вече е нараснал по размер, може да ви е трудно да излезете от RDS. Преди да вземат каквото и да е решение за преместване на вашите данни в RDS, мениджърите на информация трябва да вземат предвид изискванията и ограниченията на своята организация в конкретни области.

В следващите няколко публикации в блога ще ви покажем как да изведете данните си от RDS на отделно място. Ще обсъдим както миграцията към EC2, така и към локалната инфраструктура.