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