Секој голем проект започна со неколку сервери. Отпрвин имаше еден DB сервер, потоа на него беа додадени робови за да се зголеми читањето. И тогаш - стоп! Има еден господар, но има многу робови; ако некој од робовите замине, тогаш сè ќе биде добро, но ако господарот замине, ќе биде лошо: прекини, администраторите се обидуваат да го подигнат серверот. Што да се прави? Резервирајте господар. Мојот колега Павел веќе пишуваше за ова , нема да го повторам. Наместо тоа, ќе ви кажам зошто дефинитивно ви треба Оркестратор за MySQL!
Да почнеме со главното прашање: „Како ќе го префрлиме кодот на нова машина кога господарот ќе замине?
- Најмногу ми се допаѓа шемата со ВИП (Виртуелна ИП), за тоа ќе зборуваме подолу. Тоа е наједноставно и најочигледно, иако има очигледно ограничување: господарот што ќе го резервираме мора да биде во сегментот L2 со новата машина, односно да заборавиме на вториот DC. И, на пријателски начин, ако го следите правилото дека големото L2 е зло, бидејќи L2 е само по решетката, а L3 е помеѓу решетките, а таквата шема има уште повеќе ограничувања.
- Можете да напишете име на DNS во кодот и да го решите преку /etc/hosts. Всушност, нема да има решение. Предноста на шемата: не постои ограничување карактеристика на првиот метод, односно, можно е да се организира вкрстен DC. Но, тогаш се поставува очигледното прашање: колку брзо можеме да ја доставиме промената до /etc/hosts преку Puppet-Ansible?
- Можете малку да го промените вториот метод: инсталирајте кеширање DNS на сите веб-сервери, преку кои кодот ќе оди во главната база на податоци. Можете да поставите TTL 60 за овој запис во DNS. Се чини дека ако се спроведе правилно, методот е добар.
- Шема со откривање на услуги, што подразбира употреба на конзул и сл.
- Интересна опција со . Треба да го насочите целиот сообраќај кон MySQL преку ProxySQL; самиот ProxySQL може да одреди кој е господар. Патем, можете да прочитате за една од опциите за користење на овој производ во мојот .
Авторот на Оркестратор, работејќи во Github, прво ја имплементирал првата шема со ВИП, а потоа ја претворил во шема со конзул.
Типичен распоред на инфраструктурата:
Веднаш ќе ги опишам очигледните ситуации што треба да се земат предвид:
- ВИП адресата не треба да биде регистрирана во конфигурацијата на кој било од серверите. Ајде да замислиме ситуација: господарот се рестартира, и додека се вчитува, Оркестраторот отиде во режим на прекин и направи еден од робовите господар; тогаш се крена стариот мајстор, а сега ВИП е на две коли. Ова е лошо.
- За оркестраторот, ќе треба да напишете сценарио за повикување на стариот мајстор и новиот мајстор. На стариот мајстор треба да стартувате ifdown, а на новиот мајстор – ifup vip. Би било убаво во оваа скрипта да се вклучи и дека во случај на неуспех, портот на стариот прекинувач на мајсторот едноставно се исклучува за да се избегне каков било разделен мозок.
- Откако Orchestrator ќе ја повика вашата скрипта прво да го отстрани VIP-от и/или да ја изгаси портата на прекинувачот, а потоа да ја повика скриптата за подигање VIP на новиот мајстор, не заборавајте да ја користите командата arping за да им кажете на сите дека новиот VIP е сега овде.
- Сите робови треба да имаат read_only=1, а штом ќе го промовирате slave на господарот, тој треба да има read_only=0.
- Не заборавајте дека секој роб што го избравме за ова може да стане господар (Оркестраторот има цел механизам за преферирање кој роб да го смета како кандидат за нов господар на прво место, кој на второ место, а кој роб треба во никој случај да не биде избран господар). Ако робот стане господар, тогаш товарот на робот ќе остане на него и ќе се додаде товарот на господарот, ова мора да се земе предвид.
Зошто ви треба оркестратор ако немате?
- Оркестраторот има многу лесен графички интерфејс кој ја прикажува целата топологија (види слика од екранот подолу).
- Оркестраторот може да следи кои робови заостануваат и каде репликацијата генерално се распаѓа (имаме скрипти прикачени на Оркестраторот за испраќање СМС).
- Оркестраторот ви кажува кои робови имаат грешка во GTID.
Интерфејс на оркестраторот:
Што е GTID погрешно?
Постојат два главни барања за оркестраторот да работи:
- Неопходно е псевдо GTID да е овозможено на сите машини во кластерот MySQL; ние имаме овозможено GTID.
- Неопходно е да има еден тип на бинлогови насекаде, можете да користите изјава. Имавме конфигурација во која господарот и повеќето робови имаа Row, а двајца историски останаа во мешан режим. Како резултат на тоа, оркестраторот едноставно не сакаше да ги поврзе овие робови со новиот господар.
Запомнете дека најважното нешто во производниот роб е неговата доследност со господарот! Ако имате овозможено Глобална ИД на трансакција (GTID) и на вашиот господар и на slave, тогаш можете да ја користите функцијата gtid_subset за да дознаете дали истите барања за промени на податоците се навистина извршени на овие машини. Можете да прочитате повеќе за ова .
Така, Orchestrator ви покажува преку грешката GTID дека има трансакции на slave кои не се на господарот. Зошто се случува ова?
- Read_only=1 не е овозможено на slave, некој се поврзал и завршил барање за промена на податоците.
- Super_read_only=1 не е овозможен на slave, тогаш администраторот, откако го збуни серверот, влезе и го изврши барањето таму.
- Ако ги земете предвид двете претходни точки, тогаш има уште еден трик: во MySQL, барањето за флеш бинлогови оди и во бинлогот, така што при првото пуштање, на господарот и на сите робови ќе се појави грешка во GTID. Како да се избегне ова? Perona-5.7.25-28 ја воведе поставката binlog_skip_flush_commands=1, која забранува пишување flush на binlogs. Има воспоставено на веб-страницата mysql.com .
Дозволете ми да ги сумира сите горенаведени. Ако сè уште не сакате да го користите Оркестраторот во режим на попуштање, тогаш ставете го во режим на набљудување. Тогаш секогаш ќе имате пред очи мапа на интеракцијата на MySQL машините и визуелни информации за тоа каков тип на репликација има на секоја машина, дали робовите заостануваат и што е најважно, колку се доследни со господарот!
Очигледното прашање е: „Како треба да работи оркестраторот? Тој мора да избере нов господар од тековните робови, а потоа повторно да ги поврзе сите робови со него (ова е она за што е потребен GTID; ако го користите стариот механизам со binlog_name и binlog_pos, тогаш префрлување на slave од сегашниот господар на нов едноставно е невозможно!). Пред да имаме Оркестратор, еднаш морав да го направам сето ова рачно. Стариот господар висеше поради кабриолет контролер Adaptec; имаше околу 10 робови. Требаше да префрлам ВИП од господарот на еден од робовите и повторно да ги поврзам сите други робови со него. Колку конзоли требаше да отворам, колку симултани команди внесов... Морав да почекам до 3 часот по полноќ, да го отстранам товарот од сите робови освен две, да ја направам првата машина од два господари, веднаш да ја прикачам втората машина на него, затоа прикачете ги сите други робови на новиот господар и вратете го товарот. Генерално, страшно...
Како работи Orchestrator кога ќе премине во режим на фајловер? Ова најлесно се илустрира со пример на ситуација кога сакаме од мајсторот да направиме помоќна, помодерна машина отколку што ја имаме сега.
Сликата ја покажува средината на процесот. Што е веќе направено до овој момент? Рековме дека сакаме да направиме некој роб нов господар, Оркестраторот почна едноставно повторно да ги поврзува сите други робови со него, при што новиот господар делува како транзитна машина. Со оваа шема не се случуваат грешки, сите робови работат, Orchestrator го отстранува ВИП-то од стариот господар, го префрла на новиот, прави read_only=0 и заборава на стариот господар. Сите! Застојот на нашата услуга е времето на трансфер на ВИП, кое е 2-3 секунди.
Тоа е се за денес, ви благодарам на сите. Наскоро ќе има втора статија за Оркестраторот. Во познатиот советски филм „Гаража“, еден лик рече: „Не би одел на извидување со него! Значи, оркестратор, би одел со тебе на извидување!
Извор: www.habr.com