Кез келген үлкен жоба бірнеше серверлерден басталды. Алдымен бір МҚ сервері болды, содан кейін оқуды масштабтау үшін оған құлдар қосылды. Сосын - тоқта! Қожайын біреу, бірақ құл көп; егер құлдардың біреуі кетсе, онда бәрі жақсы болады, бірақ егер шебер кетсе, жаман болады: үзіліс, әкімшілер серверді көтеруге тырысады. Не істеу? Мастерді брондау. Бұл туралы менің әріптесім Павел жазған болатын , Мен оны қайталамаймын. Оның орнына мен сізге MySQL үшін Orchestrator не үшін қажет екенін айтамын!
Негізгі сұрақтан бастайық: «Шебер кеткенде кодты жаңа машинаға қалай ауыстырамыз?»
- Маған VIP (Виртуалды IP) схемасы көбірек ұнайды, біз бұл туралы төменде айтатын боламыз. Бұл ең қарапайым және ең айқын, бірақ оның айқын шектеуі бар: біз резервке алатын шебер жаңа машинамен L2 сегментінде болуы керек, яғни біз екінші тұрақты ток туралы ұмыта аламыз. Және, достық жолмен, егер сіз үлкен L2 зұлымдық деген ережені ұстанатын болсаңыз, өйткені L2 тек бір сөреде, ал L3 тіректер арасында және мұндай схемада одан да көп шектеулер бар.
- Кодқа DNS атауын жазып, оны /etc/hosts арқылы шешуге болады. Іс жүзінде ешқандай шешім болмайды. Сұлбаның артықшылығы: бірінші әдіске тән шектеулер жоқ, яғни айқас тұрақты токты ұйымдастыруға болады. Бірақ содан кейін айқын сұрақ туындайды: өзгертуді Puppet-Ansible арқылы /etc/hosts сайтына қаншалықты жылдам жеткізе аламыз?
- Екінші әдісті аздап өзгертуге болады: барлық веб-серверлерде кэштеу DNS орнатыңыз, ол арқылы код негізгі дерекқорға өтеді. DNS жүйесінде осы жазба үшін TTL 60 орнатуға болады. Дұрыс жүзеге асырылса, әдіс жақсы болатын сияқты.
- Консулды және т.б. пайдалануды көздейтін қызметті ашу схемасы.
- бар қызықты нұсқа . Барлық трафикті MySQL-ке ProxySQL арқылы бағыттау керек; ProxySQL өзі кімнің шебер екенін анықтай алады. Айтпақшы, сіз осы өнімді пайдалану нұсқаларының бірі туралы менің мақаламнан оқи аласыз .
Github-та жұмыс істейтін Orchestrator авторы алдымен VIP-пен бірінші схеманы жүзеге асырды, содан кейін оны консулмен схемаға айналдырды.
Инфрақұрылымның типтік орналасуы:
Мен бірден ескеру қажет айқын жағдайларды сипаттаймын:
- VIP мекенжайы кез келген сервердегі конфигурацияда тіркелмеуі керек. Жағдайды елестетіп көрейік: шебер қайта жүктелді және ол жүктеліп жатқанда, Оркестр жұмыс істемеуі режиміне өтіп, құлдардың бірін шебер етті; содан кейін ескі шебер көтерілді, ал қазір VIP екі көлікте. Бұл жаман.
- Оркестр үшін ескі шеберді және жаңа шеберді шақыру сценарийін жазу керек. Ескі мастерде ifdown, ал жаңа мастерде ifup vip іске қосу керек. Сондай-ақ, осы сценарийге ақаулық орын алған жағдайда, кез келген сплитмийді болдырмау үшін ескі негізгі қосқыштағы порт жай ғана өшірілетінін қосу жақсы болар еді.
- Оркестр алдымен VIP-ті алып тастау және/немесе коммутатордағы портты өшіру үшін сценарийді шақырғаннан кейін, содан кейін жаңа мастерде VIP көтеру сценарийін шақырғаннан кейін, барлығына жаңа VIP қазір екенін айту үшін arping пәрменін пайдалануды ұмытпаңыз. Мұнда.
- Барлық құлдар тек_оқу_=1 болуы керек, ал сіз құлды қожайынға көтерген кезде, ол тек_оқу_=0 болуы керек.
- Бұл үшін біз таңдаған кез келген құл қожайын бола алатынын ұмытпаңыз (Оркестрде бірінші кезекте жаңа қожайынға үміткер ретінде қарастырылатын құлды, екінші орында және қай құлды таңдауға болатын толық таңдау механизмі бар. Ешбір жағдайда магистратураны таңдауға болмайды). Егер құл қожайын болса, онда құлдың жүгі оның үстінде қалады және қожайынның жүгі қосылады, мұны ескеру керек.
Оркестр жоқ болса, сізге не үшін керек?
- Оркестраторда бүкіл топологияны көрсететін өте ыңғайлы графикалық интерфейс бар (төмендегі скриншотты қараңыз).
- Оркестр қай құлдардың артта қалғанын және репликацияның жалпы қай жерде бұзылғанын бақылай алады (бізде SMS жіберу үшін Orchestrator бағдарламасына тіркелген сценарийлер бар).
- Оркестр сізге қай құлдарда GTID қатесі бар екенін айтады.
Оркестр интерфейсі:
GTID қатесі дегеніміз не?
Оркестрдің жұмыс істеуі үшін екі негізгі талап бар:
- Pseudo GTID MySQL кластеріндегі барлық машиналарда қосулы болуы керек; бізде GTID қосылған.
- Барлық жерде бинлогтардың бір түрі болуы керек, сіз мәлімдемені пайдалана аласыз. Бізде басты және көптеген құлдарда Row болатын, ал екеуі тарихи түрде Аралас режимде қалған конфигурацияға ие болды. Нәтижесінде Оркестр бұл құлдарды жаңа қожайынға қосқысы келмеді.
Өндірістік құлдағы ең бастысы оның қожайынмен үйлесімділігі екенін есте сақтаңыз! Егер сізде негізгі және бағынышты құрылғыларда Ғаламдық транзакция идентификаторы (GTID) қосылған болса, gtid_subset функциясын деректерді өзгертуге арналған бірдей сұраулардың осы машиналарда шынымен орындалғанын білу үшін пайдалануға болады. Бұл туралы толығырақ оқуға болады .
Осылайша, Orchestrator сізге GTID қатесі арқылы құлда шеберде жоқ транзакциялар бар екенін көрсетеді. Неліктен бұл болып жатыр?
- Read_only=1 құлда қосылмаған, біреу қосылып, деректерді өзгерту сұрауын орындады.
- Тек Super_read_only=1 құлда қосылмаған, содан кейін әкімші серверді шатастырып, кіріп, сол жерде сұрауды орындады.
- Егер сіз алдыңғы екі тармақты да ескерсеңіз, онда тағы бір трюк бар: MySQL-де бинлогтарды тазарту сұрауы да бинлогқа өтеді, сондықтан бірінші тазалау кезінде мастерде және барлық бағындаларда GTID қатесі пайда болады. Мұны қалай болдырмауға болады? Perona-5.7.25-28 binlog_skip_flush_commands=1 параметрін енгізді, ол binlogs үшін flush жазуға тыйым салады. mysql.com веб-сайтында орнатылғаны бар .
Жоғарыда айтылғандардың барлығын қорытындылауға рұқсат етіңіз. Оркестраторды ауыстырып қосу режимінде әлі пайдаланғыңыз келмесе, оны бақылау режиміне қойыңыз. Сонда сіз әрқашан сіздің көз алдыңызда MySQL машиналарының өзара әрекеттесу картасы және әрбір машинада репликацияның қандай түрі бар, құлдар артта қалды ма, және ең бастысы, олардың шебермен қаншалықты үйлесімді екендігі туралы көрнекі ақпарат болады!
Ашық сұрақ: «Оркестр қалай жұмыс істеуі керек?» Ол ағымдағы құлдардан жаңа шеберді таңдауы керек, содан кейін оған барлық құлдарды қайта қосуы керек (бұл үшін GTID қажет; егер сіз binlog_name және binlog_pos бар ескі механизмді пайдалансаңыз, онда балды ағымдағы шеберден жаңасына ауыстырыңыз жай ғана мүмкін емес!). Бізде оркестр болғанға дейін мен мұның бәрін қолмен орындауға тура келді. Ескі шебер адаптек контроллерінің салдарынан ілулі тұрды, оның 10-ға жуық құлдары болды. Маған VIP-ті шеберден құлдардың біріне көшіріп, оған барлық басқа құлдарды қайта қосу керек болды. Қанша консоль ашу керек болды, бір уақытта қанша команда енгіздім... Таңғы 3-ке дейін күту керек болды, екеуінен басқа барлық құлдардан жүкті алып тастап, екі шеберден бірінші станокты жасап, екінші станокты дереу бекітемін. оған, сондықтан барлық басқа құлдарды жаңа шеберге бекітіп, жүкті қайтарыңыз. Жалпы, қорқынышты ...
Оркестр ауыстырып қосу режиміне өткенде қалай жұмыс істейді? Мұны біз шеберді қазіргіден әлдеқайда қуатты, заманауи машина жасағымыз келетін жағдайдың мысалы арқылы оңай суреттейді.
Суретте процестің ортасы көрсетілген. Осы уақытқа дейін не істелді? Біз қандай да бір құлды жаңа қожайын еткіміз келетінін айттық, Оркестратор оған барлық басқа құлдарды қайта қосуды бастады, жаңа шебер транзиттік машина ретінде әрекет етеді. Бұл схемада қателер болмайды, барлық құлдар жұмыс істейді, Оркестр ескі шеберден VIP-ны алып тастап, оны жаңасына ауыстырады, тек read_on=0 жасайды және ескі шеберді ұмытады. Барлық! Біздің қызметіміздің тоқтап қалу уақыты VIP трансфер уақыты болып табылады, ол 2-3 секундты құрайды.
Бүгінгі күн осымен бітті, баршаңызға рахмет. Жақында Оркестр туралы екінші мақала болады. Әйгілі кеңестік «Гараж» фильмінде бір кейіпкер: «Мен онымен барлауға бармас едім!» - деді. Ендеше, оркестр, мен сізбен барлауға барар едім!
Ақпарат көзі: www.habr.com