В Citymobil използваме MySQL база данни като основно постоянно хранилище на данни. Имаме няколко клъстера от бази данни за различни услуги и цели.

Постоянната наличност на главния е критичен показател за производителността на цялата система и нейните отделни части. Автоматичното възстановяване на клъстера в случай на повреда на главния модул значително намалява времето за реакция при инцидент и времето за престой на системата. В тази статия ще разгледам дизайн с висока достъпност (HA) за MySQL клъстер, базиран на MySQL оркестратор и виртуални IP адреси (VIP).

HA решение, базирано на VIP

Първо, ще ви кажа накратко какво представлява нашата система за съхранение на данни.

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

Репликацията се извършва в полусинхронен режим въз основа на GTID. Това означава, че поне една реплика трябва да регистрира транзакция, преди да се счита за успешна. Този режим на репликация осигурява оптимален баланс между производителност и безопасност на данните в случай на повреда на главния възел. По принцип всички промени се прехвърлят от главния към използваните реплики Row Based Replication (RBR), но някои възли може да имат mixed binlog format.

Оркестраторът периодично актуализира състоянието на топологията на клъстера, анализира получената информация и при възникване на проблеми може да стартира процедура за автоматично възстановяване. Разработчикът е отговорен за самата процедура, тъй като тя може да бъде приложена по различни начини: въз основа на VIP, DNS, използване на услуги за откриване на услуги или самостоятелно написани механизми.

Един прост начин за възстановяване на главен файл, ако не успее, е да използвате плаващи VIP адреси.

Какво трябва да знаете за това решение, преди да продължите напред:

• VIP е IP адрес, който не е свързан с конкретен физически мрежов интерфейс. Ако даден възел се повреди или по време на планирана поддръжка, можем да превключим VIP на друг ресурс с минимално време на престой.
• Освобождаването и издаването на виртуален IP адрес е евтина и бърза операция.
• За да работите с VIP, имате нужда от достъп до сървъра чрез SSH или използването на специални помощни програми, например keepalived.

Нека да разгледаме възможните проблеми с нашия съветник и да си представим как трябва да работи механизмът за автоматично възстановяване.

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

1. Оркестраторът актуализира топологията на клъстера, всяка реплика съобщава, че главният е недостъпен. Оркестраторът започва процеса на избор на реплика, подходяща за ролята на новия майстор и започва възстановяването.
2. Опитваме се да премахнем ВИП-а от стария майстор - без успех.
3. Репликата преминава в ролята на майстор. Топологията се преустройва.
4. Добавяне на нов мрежов интерфейс с VIP. Тъй като не беше възможно премахването на VIP, започваме периодично да изпращаме заявка във фонов режим безплатен ARP. Този тип заявка/отговор ви позволява да актуализирате таблицата за съпоставяне на IP и MAC адреси на свързаните комутатори, като по този начин ви уведомява, че нашият VIP се е преместил. Това минимизира вероятността split brain при връщане на стария майстор.
5. Всички нови връзки незабавно се пренасочват към новия главен. Старите връзки се провалят и повтарящите се повиквания към базата данни се правят на ниво приложение.

Сървърът работи в нормален режим, възникна повреда на ниво СУБД

Алгоритъмът е подобен на предишния случай: актуализиране на топологията и стартиране на процеса на възстановяване. Тъй като сървърът е достъпен, ние успешно освобождаваме VIP на стария мастер, прехвърляме го на новия и изпращаме няколко ARP заявки. Евентуалното връщане на стария мастер не би трябвало да повлияе на възстановения клъстер и работата на приложението.

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

Неизправност на реплики или междинни мастери не води към автоматични действия и изисква ръчна намеса.

Виртуален мрежов интерфейс винаги се добавя временно, тоест след рестартиране на сървъра VIP не се присвоява автоматично. Всеки екземпляр на база данни стартира в режим само за четене по подразбиране, оркестраторът автоматично превключва новия главен за запис и се опитва да инсталира read only на стария майстор. Тези действия са насочени към намаляване на вероятността split brain.

По време на процеса на възстановяване могат да възникнат проблеми, които също трябва да бъдат уведомени чрез потребителския интерфейс на оркестратора в допълнение към стандартните инструменти за наблюдение. Разширихме REST API, като добавихме тази функция (PR в момента се преразглежда).

Общата диаграма на решението на HA е представена по-долу.

Избор на нов господар

Оркестрантът е достатъчно умен и се опитва да избира най-подходящата реплика като нов майстор по следните критерии:

• репликата изостава от майстора;
• MySQL версия на master и реплика;
• тип репликация (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 Log. Използваме тази опция, за да избегнем загубата на транзакции, когато всички кандидат-реплики изостанат.
• InstancePollSeconds — честота на изграждане и актуализиране на топологията.
• RecoveryPollSeconds — честота на топологичния анализ. Ако бъде открит проблем, се инициира възстановяване на топологията. Това постоянен, равно на 1 секунда.

Всеки клъстерен възел се запитва от оркестратора веднъж на всеки InstancePollSeconds секунди Когато бъде открит проблем, състоянието на клъстера се форсира актуализиран, след което се взема окончателното решение за извършване на възстановяване. Чрез експериментиране с различни параметри на база данни и оркестратор успяхме да намалим времето за реакция и възстановяване до 30 секунди.

изпитателен стенд

Започнахме да тестваме схемата на HA с разработването на локален изпитвателен стенд и по-нататъшно внедряване в тестови и производствени среди. Локалният щанд е напълно автоматизиран на базата на Docker и ви позволява да експериментирате с конфигурацията на оркестратора и мрежата, да мащабирате клъстера от 2-3 сървъра до няколко десетки и да провеждате упражнения в безопасна среда.

По време на упражненията ние избираме един от методите за емулация на проблема: незабавно застреляйте капитана с помощта kill -9, леко прекратете процеса и спрете сървъра (docker-compose stop), симулирайте мрежови проблеми с помощта на iptables -j REJECT или iptables -j DROP. Очакваме следните резултати:

• оркестраторът ще открие проблеми с мастера и ще актуализира топологията за не повече от 10 секунди;
• процедурата за възстановяване ще започне автоматично: мрежовата конфигурация ще се промени, ролята на главния ще премине към репликата, топологията ще бъде възстановена;
• новият мастер ще стане годен за запис, репликите на живо няма да бъдат загубени по време на процеса на възстановяване;
• данните ще започнат да се записват в новия мастер и да се репликират;
• Общото време за възстановяване ще бъде не повече от 30 секунди.

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

Данни

Здравето на основния възел на системата за съхранение е една от основните задачи на SRE и оперативния екип. Внедряването на решението за оркестратор и HA, базирано на VIP, ни позволи да постигнем следните резултати:

• надеждно откриване на проблеми с топологията на клъстера на базата данни;
• автоматична и бърза реакция на инциденти, свързани с главния, намалявайки времето за престой на системата.

Решението обаче има своите ограничения и недостатъци:

• мащабирането на HA схемата до няколко центъра за данни ще изисква една L2 мрежа между тях;
• Преди да зададем VIP на новия мастер, трябва да го освободим на стария. Процесът е последователен, което увеличава времето за възстановяване;
• освобождаването на VIP изисква SSH достъп до сървъра или друг метод за извикване на отдалечени процедури. Тъй като сървърът или базата данни изпитват проблеми, които са причинили процеса на възстановяване, не можем да сме сигурни, че премахването на VIP ще завърши успешно. А това може да доведе до появата на два сървъра с еднакъв виртуален IP адрес и проблем split brain.

Да избегна split brain, можете да използвате метода STONITH („Застреляй другия възел в главата“), който напълно изолира или деактивира проблемния възел. Има и други начини за внедряване на висока наличност на клъстер: комбинация от VIP и DNS, услуги за откриване и прокси, синхронна репликация и други методи, които имат своите недостатъци и предимства.

Говорих за нашия подход към създаването на MySQL failover cluster. Той е лесен за изпълнение и осигурява приемливо ниво на надеждност при настоящите условия. С развитието на цялата система като цяло и инфраструктурата в частност, този подход несъмнено ще се развива.

Източник: www.habr.com