Любы буйны праект пачынаўся з пары сервераў. Спачатку быў адзін DB-сервер, потым да яго дадаліся слейвы, каб маштабаваць чытанне. І тут - стоп! Майстар адзін, а слейваў шмат; калі сыдзе адзін са слейваў, тое ўсё будзе добра, а калі сыдзе майстар - будзе дрэнна: даунтайм, адміны ў мыле паднімаюць сервер. Што рабіць? Рэзерваваць майстар. Мой калега Павел ужо пісаў пра гэта , я не буду яе паўтараць. Замест гэтага раскажу, чаму вам абавязкова патрэбен Orchestrator для MySQL!
Пачнём з галоўнага пытання: Як мы будзем перамыкаць код на новую машыну пры сыходзе майстра?
- Схема з VIP (Virtual IP) мне падабаецца больш за ўсё, пра яе мы і пагаворым ніжэй. Яна самая простая і відавочная, хоць мае відавочнае абмежаванне: майстар, які мы будзем рэзерваваць, павінен знаходзіцца ў L2-сегменце з новай машынай, гэта значыць аб другім ДЦ можна забыцца. Ды і, па-добраму, калі прытрымлівацца правіла, што вялікі L2 – гэта зло, таму што L2 толькі на стойку, а паміж стойкамі L3, а такая схема мае яшчэ больш абмежаванняў.
- Можна прапісаць у кодзе DNS-імя і рэзалвіць яго праз /etc/hosts. Насамрэч рэзалю не будзе. Вартасць схемы: няма абмежавання, характэрнага для першага спосабу, гэта значыць можна і cross-ДЦ арганізаваць. Але тады ўзнікае відавочнае пытанне, як хутка мы праз Puppet-Ansible падвязем змену ў /etc/hosts.
- Можна другі спосаб трохі змяніць: на ўсіх вэб-серверах ставім які кэшуе DNS, праз які код будзе хадзіць у майстар-базу. Можна прапісаць TTL 60 для гэтага запісу ў DNS. Здаецца, што пры правільнай рэалізацыі спосаб добры.
- Схема з service discovery, якая разумее ўжыванне Consul і etcd.
- Цікавы варыянт з . Трэба ўвесь трафік на MySQL загарнуць праз ProxySQL, ProxySQL сам умее вызначаць хто зараз майстар. Дарэчы пра адзін з варыянтаў выкарыстання дадзенага прадукта можна прачытаць у маёй .
Аўтар Orchestrator, працуючы ў Github, спачатку рэалізаваў першую схему з VIP, а потым перарабіў на схему c 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 можа адсочваць, якія слейвы адсталі, а дзе рэплікацыя ўвогуле зламалася (у нас да Orchestrator прыкручаны скрыпты для адпраўкі SMS).
- Orchestrator кажа вам, на якіх слейвах есць памылка GTID errant.
Інтэрфейс Orchestrator:
Што ж такое GTID errant?
Ёсць два асноўных патрабаванні для працы Orchestrator:
- Трэба, каб на ўсіх машынах MySQL-кластара быў уключаны pseudo GTID, у нас уключаны 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