Citymobil-те біз MySQL дерекқорын негізгі тұрақты деректерді сақтау орны ретінде пайдаланамыз. Бізде әртүрлі қызметтер мен мақсаттарға арналған бірнеше дерекқор кластерлері бар.

Шебердің тұрақты болуы бүкіл жүйенің және оның жеке бөліктерінің жұмысының маңызды көрсеткіші болып табылады. Негізгі ақаулық жағдайында кластерді автоматты түрде қалпына келтіру оқиғаға жауап беру уақытын және жүйенің тоқтау уақытын айтарлықтай азайтады. Бұл мақалада мен MySQL кластері үшін жоғары қолжетімділік (HA) дизайнын қарастырамын MySQL оркестрі және виртуалды IP мекенжайлары (VIP).

VIP негізіндегі HA шешімі

Алдымен мен сізге деректерді сақтау жүйеміздің не екенін қысқаша айтып беремін.

Біз бір жазуға қол жетімді мастер және бірнеше тек оқуға арналған көшірмелері бар классикалық репликация схемасын қолданамыз. Кластер аралық шеберді қамтуы мүмкін - бұл бір мезгілде көшірме және басқалар үшін шебер болып табылатын түйін. Клиенттер көшірмелерге HAProxy арқылы қол жеткізеді, бұл жүктемені біркелкі бөлуге және оңай масштабтауға мүмкіндік береді. HAProxy пайдалану тарихи себептерге байланысты және біз қазір ProxySQL-ке көшу процесінде жатырмыз.

Репликация негізінде жартылай синхронды режимде орындалады GTID. Бұл кем дегенде бір көшірме транзакция сәтті деп саналмас бұрын оны тіркеуі керек дегенді білдіреді. Бұл репликация режимі негізгі түйін сәтсіздігі жағдайында өнімділік пен деректер қауіпсіздігі арасындағы оңтайлы теңгерімді қамтамасыз етеді. Негізінде барлық өзгерістер шеберден көшірмелерге пайдаланылады Row Based Replication (RBR), бірақ кейбір түйіндерде болуы мүмкін mixed binlog format.

Оркестр мезгіл-мезгіл кластер топологиясының күйін жаңартады, алынған ақпаратты талдайды және проблемалар туындаса, ол автоматты түрде қалпына келтіру процедурасын іске қоса алады. Әзірлеуші процедураның өзі үшін жауапты, өйткені оны әртүрлі тәсілдермен жүзеге асыруға болады: VIP, DNS негізінде, қызметті табу қызметтерін немесе өздігінен жазылған механизмдерді пайдалану.

Шеберді қалпына келтірудің бір қарапайым жолы, егер ол сәтсіз болса, өзгермелі VIP мекенжайларын пайдалану болып табылады.

Бұл шешім туралы алға жылжу алдында не білуіңіз керек:

VIP - белгілі бір физикалық желі интерфейсімен байланысты емес IP мекенжайы. Егер түйін сәтсіздікке ұшыраса немесе жоспарланған техникалық қызмет көрсету кезінде, біз VIP-ті басқа ресурсқа ең аз тоқтау уақытымен ауыстыра аламыз.
Виртуалды IP мекенжайын босату және беру - арзан және жылдам операция.
VIP-пен жұмыс істеу үшін сізге SSH арқылы серверге кіру немесе арнайы утилиталарды пайдалану қажет, мысалы, keepalived.

Шеберімізбен мүмкін болатын ақауларды қарастырайық және автоматты қалпына келтіру механизмі қалай жұмыс істейтінін елестетіп көрейік.

Шеберге желі қосылымы жоғалып кетті немесе аппараттық құрал деңгейінде мәселе туындады және сервер қолжетімсіз.

Оркестратор кластер топологиясын жаңартады, әрбір реплика шебердің қолжетімсіз екенін хабарлайды. Оркестр жаңа шебердің рөліне сәйкес келетін репликаны таңдау процесін бастайды және қалпына келтіруді бастайды.
Біз ескі шеберден VIP-ті алып тастауға тырысамыз - сәтсіз.
Көшірме шебер рөліне ауысады. Топология қайта құрылуда.
VIP арқылы жаңа желі интерфейсін қосу. VIP жою мүмкін болмағандықтан, біз мерзімді түрде фондық режимде сұрау жібере бастаймыз тегін ARP. Сұраныс/жауаптың бұл түрі қосылған қосқыштардағы IP және MAC мекенжайларын салыстыру кестесін жаңартуға мүмкіндік береді, осылайша VIP көшкені туралы хабарлайды. Бұл ықтималдылықты азайтады split brain ескі шеберді қайтарған кезде.
Барлық жаңа қосылымдар бірден жаңа шеберге қайта бағытталады. Ескі қосылымдар сәтсіз аяқталады және дерекқорға қайталанатын қоңыраулар қолданба деңгейінде жасалады.

Сервер қалыпты режимде жұмыс істейді, ДҚБЖ деңгейінде ақау орын алды

Алгоритм алдыңғы жағдайға ұқсас: топологияны жаңарту және қалпына келтіру процесін бастау. Сервер қолжетімді болғандықтан, біз ескі мастерде VIP-ті сәтті шығарамыз, оны жаңасына ауыстырамыз және бірнеше ARP сұрауларын жібереміз. Ескі шебердің мүмкін қайтарылуы қайта құрылған кластерге және қолданбаның жұмысына әсер етпеуі керек.

Басқа да мәселелер

Көшірмелердің немесе аралық шеберлердің сәтсіздігі әкелмейді автоматты әрекеттерге және қолмен араласуды талап етеді.

Виртуалды желі интерфейсі әрқашан уақытша қосылады, яғни серверді қайта жүктегеннен кейін VIP автоматты түрде тағайындалмайды. Әрбір дерекқор данасы әдепкі бойынша тек оқуға арналған режимде басталады, оркестр жаңа басты жазуды автоматты түрде ауыстырады және орнатуға тырысады. read only ескі шеберде. Бұл әрекеттер ықтималдылықты азайтуға бағытталған split brain.

Қалпына келтіру процесі кезінде проблемалар туындауы мүмкін, ол стандартты бақылау құралдарына қосымша оркестр UI арқылы хабарлануы керек. Осы мүмкіндікті қосу арқылы REST API кеңейтілді (PR қазіргі уақытта тексерілуде).

Төменде HA ерітіндісінің жалпы диаграммасы берілген.

Жаңа шеберді таңдау

Оркестр жеткілікті ақылды және таңдауға тырысады ең қолайлы көшірме келесі критерийлер бойынша жаңа магистр ретінде:

көшірме шеберден артта қалады;
Негізгі және репликаның MySQL нұсқасы;
репликация түрі (RBR, SBR немесе аралас);
бірдей немесе әртүрлі деректер орталықтарында орналасуы;
қолжетімділігі errant GTID — көшірмеде орындалған және мастерде жоқ транзакциялар;
таңдамалы таңдау ережелері де ескеріледі.

Әрбір белгі шеберлікке тамаша үміткер бола бермейді. Мысалы, көшірме деректердің сақтық көшірмесін жасау үшін пайдаланылуы мүмкін немесе серверде аппараттық құрал конфигурациясы әлсіз. Оркестр қолдайды кандидат таңдау теңшелімдерін ең таңдаулыдан еленбегенге дейін теңшеуге болатын қолмен ережелер.

Жауап беру және қалпына келтіру уақыты

Оқиға болған жағдайда жүйенің тоқтап қалу уақытын азайту маңызды, сондықтан оркестр топологиясын құруға және жаңартуға әсер ететін MySQL параметрлерін қарастырайық:

slave_net_timeout — қосылым жоғалған және қайта қосылған деп танылғанға дейін реплика шеберден жаңа деректерді немесе жүрек соғу сигналын күтетін секундтар саны. Мән неғұрлым төмен болса, реплика шебермен байланыстың үзілгенін соғұрлым жылдам анықтайды. Біз бұл мәнді 5 секундқа орнаттық.
MASTER_CONNECT_RETRY — қайта қосу әрекеттері арасындағы секундтар саны. Желі ақаулары болған жағдайда, бұл параметрдің төмен мәні жылдам қайта қосылуға мүмкіндік береді және кластерді қалпына келтіру процесінің басталуына жол бермейді. Ұсынылған мән – 1 секунд.
MASTER_RETRY_COUNT — қайта қосылу әрекеттерінің максималды саны.
MASTER_HEARTBEAT_PERIOD — секундтардағы интервал, содан кейін шебер жүрек соғу сигналын жібереді. Әдепкі мәннің жартысы slave_net_timeout.

Оркестр параметрлері:

DelayMasterPromotionIfSQLThreadNotUpToDate - тең болса true, содан кейін репликаның SQL ағыны Relay журналындағы барлық қолданылмаған транзакцияларды аяқтамайынша, басты рөл үміткер репликада қолданылмайды. Біз бұл опцияны барлық үміткер көшірмелері артта қалған кезде транзакцияларды жоғалтпау үшін пайдаланамыз.
InstancePollSeconds — топологияны құру және жаңарту жиілігі.
RecoveryPollSeconds — топологияны талдау жиілігі. Мәселе анықталса, топологияны қалпына келтіру басталады. Бұл тұрақты, 1 секундқа тең.

Әрбір кластер түйінін оркестр әр бір рет сұрайды InstancePollSeconds секунд Мәселе анықталған кезде, кластер күйі мәжбүр болады жаңартылды, содан кейін қалпына келтіруді орындау туралы соңғы шешім қабылданады. Әртүрлі дерекқор және оркестр параметрлерімен тәжірибе жасай отырып, біз жауап беру және қалпына келтіру уақытын 30 секундқа дейін қысқарта алдық.

сынақ стенді

Біз HA схемасын жергілікті әзірлеумен тестілеуді бастадық сынақ стенді және сынақ және өндірістік орталарда одан әрі енгізу. Жергілікті стенд Docker негізінде толығымен автоматтандырылған және оркестр мен желінің конфигурациясымен тәжірибе жасауға, кластерді 2-3 серверден бірнеше ондағанға дейін масштабтауға және қауіпсіз ортада жаттығулар жүргізуге мүмкіндік береді.

Жаттығулар кезінде біз проблемалық эмуляция әдістерінің бірін таңдаймыз: шеберді пайдаланып бірден түсіріңіз kill -9, процесті ақырын аяқтаңыз және серверді тоқтатыңыз (docker-compose stop), пайдалану арқылы желі мәселелерін модельдеу iptables -j REJECT немесе iptables -j DROP. Біз келесі нәтижелерді күтеміз:

оркестр 10 секундтан аспайтын уақытта шебердегі ақауларды анықтайды және топологияны жаңартады;
қалпына келтіру процедурасы автоматты түрде басталады: желі конфигурациясы өзгереді, шебердің рөлі репликаға өтеді, топология қайта құрылады;
жаңа шебер жазылатын болады, қайта құру процесінде тірі көшірмелер жоғалмайды;
деректер жаңа шеберге жазыла бастайды және қайталанады;
Қалпына келтірудің жалпы уақыты 30 секундтан аспайды.

Өздеріңіз білетіндей, жүйе әртүрлі аппараттық және желілік конфигурацияларға, синтетикалық және нақты жүктемедегі айырмашылықтарға және т.б. байланысты сынақ және өндірістік орталарда басқаша әрекет етуі мүмкін. Сондықтан біз мезгіл-мезгіл нақты жағдайларда жаттығуларды өткіземіз, желі қосылымы жоғалған немесе оның жеке бөліктері бұзылған кезде жүйенің әрекетін тексереміз. Болашақта біз екі орта үшін де толығымен бірдей инфрақұрылымды құрып, оны тестілеуді автоматтандыруды қалаймыз.

қорытындылар

Негізгі сақтау жүйесінің түйінінің денсаулығы SRE және операциялық топтың негізгі міндеттерінің бірі болып табылады. VIP негізіндегі оркестр мен HA шешімін енгізу келесі нәтижелерге қол жеткізуге мүмкіндік берді:

деректер базасының кластерінің топологиясымен проблемаларды сенімді анықтау;
шеберге қатысты оқиғаларға автоматты және жылдам әрекет ету, жүйенің тоқтап қалу уақытын азайту.

Дегенмен, шешімнің шектеулері мен кемшіліктері бар:

HA схемасын бірнеше деректер орталықтарына масштабтау олардың арасында бір L2 желісін қажет етеді;
Жаңа мастерге VIP тағайындамас бұрын, оны ескісіне шығару керек. Процесс дәйекті, бұл қалпына келтіру уақытын арттырады;
VIP шығару серверге SSH рұқсатын немесе қашықтағы процедураларды шақырудың кез келген басқа әдісін талап етеді. Серверде немесе дерекқорда қалпына келтіру процесін тудырған мәселелер туындағандықтан, VIP жою сәтті аяқталатынына сенімді бола алмаймыз. Және бұл бірдей виртуалды IP мекенжайы бар екі сервердің пайда болуына және мәселеге әкелуі мүмкін split brain.

Болдырмау үшін split brain, әдісін қолдануға болады СТОНИТ («Бастағы басқа түйінді түсіріңіз»), ол проблемалық түйінді толығымен оқшаулайды немесе өшіреді. Кластердің жоғары қолжетімділігін жүзеге асырудың басқа жолдары бар: VIP және DNS комбинациясы, қызметті табу және прокси қызметтері, синхронды репликация және өздерінің кемшіліктері мен артықшылықтары бар басқа әдістер.

Мен MySQL ауыспалы кластерін құру тәсілі туралы айттым. Оны жүзеге асыру оңай және ағымдағы жағдайларда сенімділіктің қолайлы деңгейін қамтамасыз етеді. Тұтастай алғанда бүкіл жүйе және атап айтқанда, инфрақұрылым дамыған сайын бұл тәсіл сөзсіз дамиды.

Ақпарат көзі: www.habr.com

MySQL кластеріне арналған HA шешімі ретінде оркестр және VIP