Во Citymobil користиме MySQL база на податоци како наше главно постојано складирање на податоци. Имаме неколку кластери за бази на податоци за различни услуги и цели.

Постојаната достапност на мајсторот е критичен показател за перформансите на целиот систем и неговите поединечни делови. Автоматското враќање на кластерот во случај на дефект на главниот во голема мера го намалува времето на одговор на инцидентот и времето на прекин на системот. Во оваа статија, ќе разгледам дизајн со висока достапност (HA) за кластер MySQL заснован на MySQL оркестратор и виртуелни IP адреси (VIP).

HA решение базирано на ВИП

Прво, накратко ќе ви кажам кој е нашиот систем за складирање податоци.

Ние користиме класична шема за репликација со еден господар достапен за пишување и повеќе реплики само за читање. Кластерот може да содржи среден господар - јазол кој е и реплика и господар за другите. Клиентите пристапуваат до репликите преку HAProxy, што овозможува рамномерна распределба на оптоварувањето и лесно скалирање. Употребата на HAProxy се должи на историски причини и моментално сме во процес на мигрирање на ProxySQL.

Репликацијата се изведува во полу-синхрони режим врз основа на GTID. Ова значи дека барем една реплика мора да ја најави трансакцијата пред да се смета за успешна. Овој режим на репликација обезбедува оптимална рамнотежа помеѓу перформансите и безбедноста на податоците во случај на дефект на главниот јазол. Во основа, сите промени се пренесуваат од главниот во репликите користејќи Row Based Replication (RBR), но некои јазли може да имаат mixed binlog format.

Оркестраторот периодично ја ажурира состојбата на топологијата на кластерот, ги анализира добиените информации и ако се појават проблеми, може да започне автоматска процедура за обновување. Инвеститорот е одговорен за самата процедура, бидејќи може да се спроведе на различни начини: врз основа на VIP, DNS, користејќи услуги за откривање услуги или механизми самостојно напишани.

Еден едноставен начин да го вратите господарот ако не успее е да користите лебдечки ВИП адреси.

Што треба да знаете за ова решение пред да продолжите понатаму:

ВИП е IP адреса која не е поврзана со специфичен физички мрежен интерфејс. Ако некој јазол не успее или за време на планираното одржување, можеме да го префрлиме VIP-от на друг ресурс со минимално застој.
Ослободувањето и издавањето виртуелна IP адреса е евтина и брза операција.
За да работите со VIP, потребен ви е пристап до серверот преку SSH или користење на специјални комунални услуги, на пример, keepalived.

Да ги погледнеме можните проблеми со нашиот волшебник и да замислиме како треба да работи механизмот за автоматско обновување.

Мрежно поврзување со господарот исчезна или се појави проблем на хардверско ниво и серверот е недостапен

Оркестраторот ја ажурира топологијата на кластерот, секоја реплика известува дека мајсторот е недостапен. Оркестраторот го започнува процесот на избор на реплика погодна за улогата на новиот мајстор и започнува со закрепнување.
Се обидуваме да го отстраниме ВИП-то од стариот мајстор - безуспешно.
Репликата се префрла на улогата на господар. Се реконструира топологијата.
Додавање нов мрежен интерфејс со ВИП. Бидејќи не беше можно да се отстрани ВИП-то, почнуваме периодично да испраќаме барање во позадина бесплатен ARP. Овој тип на барање/одговор ви овозможува да ја ажурирате табелата за мапирање на IP и MAC адреси на поврзаните прекинувачи, со што ќе ве известиме дека нашиот ВИП е преместен. Ова ја минимизира веројатноста split brain при враќањето на стариот мајстор.
Сите нови врски веднаш се пренасочуваат кон новиот господар. Старите врски не успеваат и се прават повторени повици до базата на податоци на ниво на апликација.

Серверот работи во нормален режим, се случи дефект на ниво на DBMS

Алгоритмот е сличен на претходниот случај: ажурирање на топологијата и започнување на процесот на обновување. Бидејќи серверот е достапен, успешно го ослободуваме ВИП-то на стариот господар, го пренесуваме на новиот и испраќаме неколку ARP барања. Можното враќање на стариот господар не треба да влијае на повторно изградениот кластер и работата на апликацијата.

Други проблеми

Неуспех на реплики или средни мајстори не води на автоматски дејства и бара рачна интервенција.

Виртуелниот мрежен интерфејс секогаш се додава привремено, односно, по рестартирање на серверот, ВИП-то не се доделува автоматски. Секој примерок од базата на податоци стандардно започнува во режим само за читање, оркестраторот автоматски го префрла новиот мајстор да пишува и се обидува да инсталира read only на стариот мајстор. Овие активности се насочени кон намалување на веројатноста split brain.

Може да се појават проблеми за време на процесот на обновување, што треба да биде известено и преку интерфејсот на оркестраторот, покрај стандардните алатки за следење. Го проширивме 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 нишката на репликата не ги заврши сите неприменети трансакции од Релејниот дневник. Ја користиме оваа опција за да избегнеме губење трансакции кога сите реплики кандидати заостануваат.
InstancePollSeconds — фреквенција на градење и ажурирање на топологијата.
RecoveryPollSeconds — фреквенција на тополошка анализа. Ако се открие проблем, се започнува со обновување на топологијата. Ова постојана, еднакво на 1 секунда.

Секој кластер јазол е анкетиран од оркестраторот еднаш на секои InstancePollSeconds секунди Кога ќе се открие проблем, состојбата на кластерот е принудена ажурирани, а потоа се носи конечната одлука за извршување на закрепнување. Со експериментирање со различна база на податоци и параметри на оркестраторот, успеавме да го намалиме времето на одговор и обновување на 30 секунди.

Тест штанд

Почнавме да ја тестираме шемата за HA со развојот на локална тест клупа и понатамошна имплементација во средини за тестирање и производство. Локалниот штанд е целосно автоматизиран врз основа на Docker и ви овозможува да експериментирате со конфигурацијата на оркестраторот и мрежата, да го зголемите кластерот од 2-3 сервери на неколку десетици и да изведувате вежби во безбедно опкружување.

За време на вежбите, избираме еден од методите за емулација на проблемот: веднаш пукајте го мајсторот користејќи kill -9, нежно прекинете го процесот и стопирајте го серверот (docker-compose stop), симулирајте мрежни проблеми користејќи iptables -j REJECT или iptables -j DROP. Ги очекуваме следните резултати:

оркестраторот ќе открие проблеми со мајсторот и ќе ја ажурира топологијата за не повеќе од 10 секунди;
постапката за обновување автоматски ќе започне: конфигурацијата на мрежата ќе се промени, улогата на мајсторот ќе премине на репликата, топологијата ќе биде повторно изградена;
новиот господар ќе може да се запише, репликите во живо нема да се изгубат за време на процесот на обнова;
податоците ќе почнат да се запишуваат на новиот господар и да се реплицираат;
Вкупното време за опоравување нема да биде повеќе од 30 секунди.

Како што знаете, системот може да се однесува поинаку во средини за тестирање и производство поради различни хардверски и мрежни конфигурации, разлики во синтетичкото и реалното оптоварување итн. Затоа, ние периодично спроведуваме вежби во реални услови, проверувајќи како се однесува системот кога се губи мрежното поврзување или неговите поединечни делови се деградирани. Во иднина сакаме да изградиме целосно идентична инфраструктура за двете средини и да го автоматизираме нејзиното тестирање.

Наоди

Здравјето на главниот јазол на системот за складирање е една од главните задачи на SRE и оперативниот тим. Имплементацијата на решението за оркестратор и ХА засновано на ВИП ни овозможи да ги постигнеме следните резултати:

сигурно откривање на проблеми со топологијата на кластерот на базата на податоци;
автоматско и брзо реагирање на инциденти поврзани со мајсторот, намалувајќи го времето на прекин на системот.

Сепак, решението има свои ограничувања и недостатоци:

скалирањето на HA шемата на неколку центри за податоци ќе бара единствена L2 мрежа помеѓу нив;
Пред да доделиме ВИП на новиот господар, треба да го ослободиме на стариот. Процесот е последователен, што го зголемува времето на закрепнување;
ослободувањето на ВИП бара SSH пристап до серверот или кој било друг метод за повикување далечински процедури. Бидејќи серверот или базата на податоци се соочуваат со проблеми што го предизвикаа процесот на обновување, не можеме да бидеме сигурни дека отстранувањето на ВИП ќе заврши успешно. И ова може да доведе до појава на два сервери со иста виртуелна IP адреса и проблем split brain.

За да се избегне split brain, можете да го користите методот СТОНИТ („Снимајте го другиот јазол во главата“), што целосно го изолира или оневозможува проблематичниот јазол. Постојат и други начини за имплементација на висока достапност на кластерот: комбинација на VIP и DNS, услуги за откривање услуги и прокси, синхрона репликација и други методи кои имаат свои недостатоци и предности.

Зборував за нашиот пристап кон креирање кластер за фајловер на MySQL. Лесно е да се имплементира и обезбедува прифатливо ниво на сигурност во сегашните услови. Како што се развива целиот систем воопшто и инфраструктурата особено, овој пристап несомнено ќе се развива.

Извор: www.habr.com

Оркестратор и ВИП како HA решение за MySQL кластер