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 эски кожоюнду кайтарып жатканда.
Бардык жаңы байланыштар дароо жаңы мастерге багытталат. Эски байланыштар иштебей калат жана маалымат базасына кайталанган чалуулар колдонмо деңгээлинде жасалат.

Сервер кадимки режимде иштеп жатат, DBMS деңгээлинде ката кетти

Алгоритм мурунку учурга окшош: топологияны жаңылоо жана калыбына келтирүү процессин баштоо. Сервер жеткиликтүү болгондуктан, биз VIPти эски мастерге ийгиликтүү чыгарып, аны жаңысына өткөрүп, бир нече ARP сурамдарын жөнөтөбүз. Эски кожоюндун мүмкүн болгон кайтарылышы кайра курулган кластерге жана тиркеменин иштешине таасирин тийгизбеши керек.

башка маселелер

Репликалардын же аралык мастерлердин иштебей калышы алып келбейт автоматтык аракеттерге жана кол менен кийлигишүүнү талап кылат.

Виртуалдык тармак интерфейси ар дайым убактылуу кошулат, башкача айтканда, сервер кайра жүктөлгөндөн кийин, VIP автоматтык түрдө дайындалбайт. Ар бир маалымат базасы демейки боюнча окуу үчүн гана режимде башталат, оркестр автоматтык түрдө жаңы мастерди жазууга которот жана орнотууга аракет кылат read only эски устата. Бул иш-аракеттер ыктымалдыгын азайтууга багытталган split brain.

Калыбына келтирүү процессинде көйгөйлөр келип чыгышы мүмкүн, алар стандарттык мониторинг куралдарынан тышкары оркестрдин интерфейси аркылуу да билдирилиши керек. Бул функцияны кошуу менен REST API кеңейттик (PR учурда каралып жатат).

HA чечиминин жалпы диаграммасы төмөндө келтирилген.

Жаңы мастер тандоо

Оркестр жетиштүү акылдуу жана тандоого аракет кылат эң ылайыктуу реплика төмөнкү критерийлер боюнча жаңы мастер катары:

реплика мастерден артта калат;
Master жана репликанын 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 өчүрүү кластерин түзүүгө болгон мамилебиз жөнүндө сүйлөштүм. Аны ишке ашыруу оңой жана учурдагы шарттарда ишенимдүүлүктүн алгылыктуу деңгээлин камсыз кылат. Бүтүндөй система жана өзгөчө инфраструктура өнүккөн сайын, бул ыкма сөзсүз түрдө өнүгөт.

Source: www.habr.com

MySQL кластери үчүн HA чечими катары Оркестр жана VIP