Всеки голям проект започва с няколко сървъра. Първоначално имаше един DB-сървър, след това към него се добавиха слейвове, за да се мащабира четенето. И тук - стоп! Мастърът е един, а слейвовете са много; ако един от слейвовете отпадне, всичко ще бъде наред, но ако отпадне мастърът - ще бъде лошо: даунтайм, администраторите в паника ще подемат сървъра. Какво да правим? Резервирайте мастър. Моят колега Павел вече е писал за това , няма да я повтарям. Вместо това ще разкажа защо задължително ви трябва Orchestrator за MySQL!
Започваме с главния въпрос: «Как ще превключим кода на новата машина при отпадане на мастъра?».
- Схемата с VIP (Virtual IP) ми харесва най-много, за нея ще говорим по-долу. Тя е най-простата и очевидна, въпреки че има ясно ограничение: мастърът, който ще резервираме, трябва да се намира в L2-сегмента с новата машина, т.е. за втория ДЦ можем да забравим. И, по-добре, ако следваме правилото, че голямото L2 е зло, тъй като L2 е само на рафт, а между рафтовете е L3, а такава схема има още по-големи ограничения.
- Можем да запишем в кода DNS-името и да го резолвим чрез /etc/hosts. Всъщност резолвиране няма да има. Предимството на схемата: няма ограничение, характерно за първия начин, т.е. можем да организираме и cross-ДЦ. Но тогава възниква очевидният въпрос, колко бързо ще внесем промяната в /etc/hosts чрез Puppet-Ansible.
- Можем малко да променим втория начин: на всички уеб-сървъри инсталираме кеширащ DNS, през който кодът ще отива в мастър-базата. Можем да запишем TTL 60 за тази записка в DNS. Изглежда, че при правилна реализация начинът е добър.
- Схемата с откриване на услуги, предвиждаща използването на Consul и etcd.
- Интересен вариант с . Нужно е весь трафик на MySQL да минава през ProxySQL, ProxySQL сам знае кой в момента е мастър. Специално за един от вариантите на използване на този продукт можете да прочетете в моята .
Авторът на Orchestrator, работещ в Github, първоначално реализира първата схема с VIP, а след това я преобразува в схема с consul.
Типична схема на инфраструктурата:
Веднага ще опиша очевидните ситуации, които трябва да се вземат под внимание:
- VIP адресът не трябва да бъде записан в конфигурацията на нито един от сървърите. Да предположим ситуация: майсторът се е рестартира, а докато се зарежда, Orchestrator преминава в режим на failover и прави един от слейвовете майстор; след това се стартира старият майстор и сега VIP е на две машини. Това е проблем.
- За Orchestrator ще е необходимо да напишете скрипт, който да се свързва с стария и новия майстор. На стария трябва да се изпълни ifdown, а на новия майстор — ifup vip. Би било добре в този скрипт да се впише, че в случай на failover портът на комутатора на стария майстор просто да се изключи, за да се избегне всякакво splitbrain.
- След като Orchestrator е извикал вашия скрипт, за да премахне VIP и/или да изключи порта на комутатора, а след това на новия майстор да извика скрипта за активиране на VIP, не забравяйте с командата arping да кажете на всички, че новият VIP сега е тук.
- На всички слейвове трябва да има read_only=1, а веднага след като промотирате слейва до майстор, той трябва да стане read_only=0.
- Не забравяйте, че майстор може да стане всеки слейв, който сме избрали за това (Orchestrator има цял механизъм за предпочитания на кой слейв да се разглежда като кандидат за нов майстор на първо място, кой на второ, а кой слейв никога при никакви обстоятелства не трябва да бъде избран за майстор). Ако слейвът стане майстор, на него ще остане натоварването на слейва и ще се добави натоварването на майстора, което трябва да се вземе предвид.
Защо наистина ви е необходим Orchestrator, ако нямате такъв?
- Orchestrator разполага с много удобен графичен интерфейс, който показва цялата топология (вижте екрана по-долу).
- Orchestrator може да проследява кои слейвове закъсняват и къде репликацията изобщо е спряла (в нашия случай към Orchestrator са свързани скриптове за изпращане на SMS).
- Orchestrator ви казва на кои слейвове има грешка GTID errant.
Интерфейс на Orchestrator:
Какво е GTID errant?
Има две основни изисквания за работа на Orchestrator:
- Трябва да е включен pseudo GTID на всички машини в MySQL кластера, при нас е активиран GTID.
- Трябва на всякъде да има един тип бинлогове, може statement. Имахме такава конфигурация, при която на майстора и на повечето слейвове е бил Row, а на две исторически е останал режим Mixed. В резултат на това тези слейвове Orchestrator просто не пожела да свърже с новия майстор.
Помнете, че най-важното в production слейв е неговата консистентност с мастера! Ако както на мастера, така и на слейва е включен Global Transaction ID (GTID), то чрез функцията gtid_subset можете да разберете дали на тези машини са изпълнени едни и същи заявки за промяна на данни. Повече информация по темата можете да прочетете тук. .
Така Orchestrator ви показва чрез грешка GTID errant, че на слейва има транзакции, които не съществуват на мастера. Защо се случва така?
- На слейва не е включен read_only=1, някой се е свързал и е извършил заявка за промяна на данни.
- На слейва не е включен super_read_only=1, и администратор, обърквайки сървъра, е влязъл и е изпълнил там заявка.
- Ако сте взели предвид и двата предишни пункта, то има още един трик: в MySQL заявката за flush на бинлоговете също попада в бинлог, така че при първото flush на мастера и на всички слейвове ще се появи GTID errant. Как да го избегнете? В perona-5.7.25-28 се появи настройка binlog_skip_flush_commands=1, която забранява записването на flush в бинлоговете. На сайта mysql.com има създаден .
Резюмирам всичко казано. Ако все още не искате да използвате Orchestrator в режим failover, поставете го в режим наблюдение. Тогава винаги ще имате пред очите си карта на взаимодействието между MySQL машините и нагледна информация за това какъв тип репликация има на всяка машина, изостават ли слейвовете и най-важното — колко консистентни са спрямо мастера!
Очевидният въпрос е: «Как трябва да работи Orchestrator?». Той трябва да избере нов мастер от текущите слейвове и след това да пренасочи всички слейвове към него (в именно за това е нужен GTID; ако използвате стария механизъм с binlog_name и binlog_pos, то прехвърлянето на слейв от текущия мастер на нов е просто невъзможно!). Преди да се появи Orchestrator, веднъж ми се наложи да правя всичко това ръчно. Старият мастер замръзваше заради дефектен контролер Adaptec, имаше около 10 слейва. Трябваше да прехвърля VIP от мастера на един от слейвовете и да пренасоча всички останали слейвове към него. Колко конзоли трябваше да отворя, колко команди едновременно да въведа… Трябваше да изчакам до 3 часа сутринта, да сваля натоварването от всички слейвове, освен от два, да направя мастър първата машина от двете, веднага да я свържа с втората, след това към новия мастер да свържа всички останали слейсове и да върна натоварването. Общо взето, ужас…
Как работи Orchestrator, когато премине в режим failover? Най-лесно е да го демонстрираме с пример, когато искаме да направим по-мощна, по-съвременна машина за мастер от текущата.
На схемата е показана средата на процеса. Какво е направено до този момент? Казахме, че искаме да направим един от слейвите нов мастер, Orchestrator започна просто да свързва всички останали слейви към него, като новият мастер изпълнява ролята на транзитна машина. При тази схема не възникват грешки, всички слейви работят, Orchestrator сваля VIP от стария мастер, прехвърля го на новия, настройва read_only=0 и забравя за стария мастер. Всичко! Даунаутаймът на нашата услуга е времето за прехвърляне на VIP, което е 2-3 секунди.
Днес всичко, благодаря на всички. Скоро ще има втора статия за Orchestrator. В известния съветски филм „Гараж“ един герой каза „Не бих отишъл с него на разузнаване!“ Така че, Orchestrator, с теб бих отишъл на разузнаване!
Източник: habr.com
