Всеки голям проект започва с няколко сървъра. Отначало имаше един DB сървър, след това към него бяха добавени робове, за да мащабират четенето. И тогава - спри! Има един господар, но има много роби; ако един от робовете напусне, тогава всичко ще бъде наред, но ако главният напусне, ще бъде лошо: престой, администраторите се опитват да вдигнат сървъра. Какво да правя? Запазете майстор. Колегата Павел вече писа за това , няма да го повтарям. Вместо това ще ви кажа защо определено имате нужда от Orchestrator за MySQL!
Нека започнем с основния въпрос: „Как ще превключим кода на нова машина, когато главният напусне?“
- Най-много ми харесва схемата с VIP (Virtual IP), за нея ще говорим по-долу. Той е най-простият и очевиден, въпреки че има очевидно ограничение: мастърът, който ще запазим, трябва да бъде в L2 сегмента с новата машина, тоест можем да забравим за втория DC. И по приятелски начин, ако следвате правилото, че голям L2 е зло, защото L2 е само на стелаж, а L3 е между стелажите и такава схема има още повече ограничения.
- Можете да напишете DNS име в кода и да го разрешите чрез /etc/hosts. Всъщност резолюция няма да има. Предимството на схемата: няма ограничение, характерно за първия метод, т.е. възможно е да се организира кръстосано постоянен ток. Но тогава възниква очевидният въпрос: колко бързо можем да доставим промяната на /etc/hosts чрез Puppet-Ansible?
- Можете да промените малко втория метод: инсталирайте кеширане на DNS на всички уеб сървъри, чрез които кодът ще отиде в главната база данни. Можете да зададете TTL 60 за този запис в DNS. Изглежда, че ако се прилага правилно, методът е добър.
- Схема с откриване на услуга, предполагаща използването на Consul и др.
- Интересен вариант с . Трябва да насочите целия трафик към MySQL през ProxySQL; самият ProxySQL може да определи кой е главният. Между другото, можете да прочетете за една от опциите за използване на този продукт в моя .
Авторът на Orchestrator, работещ в Github, първо внедри първата схема с VIP и след това я преобразува в схема с консул.
Типично оформление на инфраструктурата:
Веднага ще опиша очевидните ситуации, които трябва да бъдат взети под внимание:
- VIP адресът не трябва да бъде регистриран в конфигурацията на нито един от сървърите. Нека си представим ситуация: главният се рестартира и докато се зарежда, Orchestrator влезе в режим на отказ и направи един от робовете главен; тогава старият майстор стана, а сега ВИП-ът е на две коли. Това е лошо.
- За оркестратора ще трябва да напишете сценарий за извикване на стария майстор и новия майстор. На стария мастер трябва да стартирате ifdown, а на новия мастер – ifup vip. Би било хубаво в този скрипт също да се включи, че в случай на отказ, портът на стария главен превключвател просто се изключва, за да се избегне сплитмозък.
- След като Orchestrator извика скрипта ви, за да премахне първо VIP и/или загаси порта на комутатора и след това извика скрипта за повишаване на VIP на новия главен, не забравяйте да използвате командата arping, за да кажете на всички, че новият VIP е вече тук.
- Всички подчинени устройства трябва да имат read_only=1 и веднага щом повишите подчинения до главен, той трябва да има read_only=0.
- Не забравяйте, че всеки роб, който сме избрали за това, може да стане господар (Orchestrator има цял механизъм за предпочитания за това кой роб да счита за кандидат за нов господар на първо място, кой на второ място и кой роб трябва да не се избира изобщо при никакви обстоятелства майстор). Ако робът стане главен, тогава товарът на роба ще остане върху него и ще се добави товарът на главния, това трябва да се вземе предвид.
Защо ви трябва Orchestrator, ако нямате такъв?
- Orchestrator има много удобен за потребителя графичен интерфейс, който показва цялата топология (вижте екранната снимка по-долу).
- Orchestrator може да проследи кои подчинени устройства изостават и къде репликацията обикновено е прекъсната (имаме скриптове, прикачени към Orchestrator за изпращане на SMS).
- Orchestrator ви казва кои подчинени устройства имат грешен GTID.
Интерфейс на оркестратора:
Какво е грешен GTID?
Има две основни изисквания за работа на Orchestrator:
- Необходимо е псевдо GTID да е активиран на всички машини в MySQL клъстера; имаме активиран GTID.
- Необходимо е навсякъде да има един тип binlog, можете да използвате statement. Имахме конфигурация, в която главният и повечето подчинени устройства имаха ред, а два исторически останаха в смесен режим. В резултат на това Orchestrator просто не искаше да свърже тези роби с новия господар.
Не забравяйте, че най-важното нещо в производствения роб е неговата последователност с господаря! Ако имате активиран глобален идентификатор на транзакция (GTID) както на главния, така и на подчинения, тогава можете да използвате функцията gtid_subset, за да разберете дали същите заявки за промени в данните действително са били изпълнени на тези машини. Можете да прочетете повече за това .
По този начин Orchestrator ви показва чрез грешката на GTID, че има транзакции на подчинения, които не са на главния. Защо се случва това?
- Read_only=1 не е активиран на подчинено устройство, някой се е свързал и е изпълнил заявка за промяна на данните.
- Super_read_only=1 не е активиран на slave, тогава администраторът, след като е объркал сървъра, е влязъл и е изпълнил заявката там.
- Ако сте взели предвид и двете предишни точки, тогава има още един трик: в MySQL, заявка за изчистване на binlogs също отива към binlog, така че при първото промиване GTID errant ще се появи на главния и всички подчинени. Как да избегнем това? Perona-5.7.25-28 въведе настройката binlog_skip_flush_commands=1, която забранява записването на флъш в binlogs. Има установен такъв на уебсайта mysql.com .
Позволете ми да обобщя всичко по-горе. Ако все още не искате да използвате Orchestrator в режим на отказ, поставете го в режим на наблюдение. Тогава винаги ще имате пред очите си карта на взаимодействието на MySQL машини и визуална информация за това какъв тип репликация има на всяка машина, дали робите изостават и най-важното колко са последователни с главния!
Очевидният въпрос е: „Как трябва да работи Orchestrator?“ Той трябва да избере нов главен от текущите подчинени устройства и след това да свърже отново всички подчинени устройства към него (за това е необходим GTID; ако използвате стария механизъм с binlog_name и binlog_pos, след това превключете подчинено устройство от текущия главен към нов е просто невъзможно!). Преди да имаме Orchestrator, веднъж трябваше да направя всичко това ръчно. Старият мастер висеше поради бъгав контролер на Adaptec, имаше около 10 роба. Трябваше да прехвърля VIP от главния към един от подчинените устройства и да свържа отново всички други подчинени устройства към него. Колко конзоли трябваше да отворя, колко едновременни команди въведох... Трябваше да изчакам до 3 сутринта, да премахна товара от всички подчинени устройства с изключение на два, да направя първата машина от две главни, веднага да прикача втората машина към него, така че прикрепете всички останали роби към новия главен и върнете товара. Като цяло, ужасно...
Как работи Orchestrator, когато премине в режим на отказ? Това най-лесно може да се илюстрира с пример за ситуация, в която искаме да направим мастер по-мощна, по-модерна машина, отколкото имаме сега.
Фигурата показва средата на процеса. Какво вече е направено до този момент? Казахме, че искаме да направим някакъв роб новия главен, Orchestrator започна просто да свързва отново всички други роби към него, като новият главен действаше като транзитна машина. При тази схема не възникват грешки, всички slave работят, Orchestrator премахва VIP от стария master, прехвърля го на новия, прави read_only=0 и забравя за стария master. Всичко! Прекъсването на нашата услуга е времето за VIP трансфер, което е 2-3 секунди.
Това е всичко за днес, благодаря на всички. Скоро ще има втора статия за Orchestrator. В известния съветски филм "Гараж" един герой каза: "Не бих отишъл на разузнаване с него!" Така че, оркестратор, бих тръгнал с вас на разузнаване!
Източник: www.habr.com