Оркестратор за МиСКЛ: зашто не можете да направите пројекат отпоран на грешке без њега

Сваки велики пројекат је почео са неколико сервера. У почетку је постојао један ДБ сервер, а затим су му додани славе ради скалирања очитавања. А онда – стани! Један је господар, али има много робова; ако неко од робова оде, онда ће све бити у реду, али ако мастер оде, биће лоше: застоји, администратори покушавају да подигну сервер. Шта да радим? Резервишите мајстора. Мој колега Павел је већ писао о томе статью, нећу то понављати. Уместо тога, рећи ћу вам зашто вам је дефинитивно потребан Орцхестратор за МиСКЛ!

Почнимо са главним питањем: „Како ћемо пребацити код на нову машину када господар оде?“

• Највише ми се свиђа шема са ВИП (виртуелним ИП-ом), о томе ћемо у наставку. То је најједноставнији и најочигледнији, иако има очигледно ограничење: мастер који ћемо резервисати мора бити у сегменту Л2 са новом машином, односно можемо заборавити на други ДЦ. И, на пријатељски начин, ако се придржавате правила да је велики Л2 зао, јер је Л2 само по рацк-у, а Л3 је између регала, а таква шема има још више ограничења.
• Можете написати ДНС име у коду и решити га преко /етц/хостс. У ствари, неће бити никаквог решења. Предност шеме: не постоји ограничење карактеристично за први метод, односно могуће је организовати унакрсни ДЦ. Али онда се поставља очигледно питање: колико брзо можемо да испоручимо промену на /етц/хостс преко Пуппет-Ансибле?
• Други метод можете мало да промените: инсталирајте ДНС за кеширање на све веб сервере, преко којих ће код ићи у главну базу података. Можете подесити ТТЛ 60 за овај унос у ДНС-у. Чини се да ако се правилно примени, метода је добра.
• Шема са откривањем услуге, која подразумева коришћење Цонсул и етцд.
• Занимљива опција са ПрокиСКЛ. Морате да усмерите сав саобраћај на МиСКЛ кроз ПрокиСКЛ; ПрокиСКЛ сам може да одреди ко је главни. Иначе, о једној од опција за коришћење овог производа можете прочитати у мом Чланак.

Аутор Орцхестратор-а, који ради у Гитхубу, прво је имплементирао прву шему са ВИП-ом, а затим је конвертовао у шему са конзулом.

Типичан распоред инфраструктуре:

Одмах ћу описати очигледне ситуације које треба узети у обзир:

• ВИП адреса не би требало да буде регистрована у конфигурацији ни на једном серверу. Замислимо ситуацију: мастер се поново покренуо, и док се учитавао, Орцхестратор је прешао у режим преласка на грешку и једног од славеова направио мастер; тада се дигао стари мајстор, а сада је ВИП на два аута. Ово је лоше.
• За оркестратора, мораћете да напишете скрипту за позивање старог и новог мајстора. На старом мастеру треба да покренете ифдовн, а на новом мастеру – ифуп вип. Било би лепо да се у ову скрипту такође укључи да се у случају грешке, порт на прекидачу старог мастера једноставно искључује како би се избегао било какав подељени мозак.
• Након што Орцхестратор позове вашу скрипту да прво уклони ВИП и/или угаси порт на прекидачу, а затим позове скрипту за подизање ВИП на новом мастеру, не заборавите да користите команду арпинг да бисте свима рекли да је нови ВИП сада овде.
• Сви славе-ови треба да имају реад_онли=1, а чим унапредите славе у мастер, требало би да има реад_онли=0.
• Не заборавите да сваки роб којег смо изабрали за ово може постати господар (Оркестратор има читав механизам преференције за кога роба треба узети у обзир кандидата за новог господара на првом месту, кога на другом месту, а којег роба треба ни под којим околностима не буде изабран мајстор). Ако славе постане мастер, онда ће оптерећење славе остати на њему и оптерећење мастера ће се додати, ово се мора узети у обзир.

Зашто вам треба Оркестратор ако га немате?

• Орцхестратор има веома једноставан графички интерфејс који приказује целу топологију (погледајте снимак екрана испод).
• Орцхестратор може да прати који славе заостају и где је репликација генерално прекинута (имамо скрипте прикачене на Орцхестратор за слање СМС-а).
• Орцхестратор вам говори који робови имају грешку у ГТИД-у.

Интерфејс оркестратора:

Шта је ГТИД погрешан?

Постоје два главна услова за рад Оркестратора:

• Неопходно је да је псеудо ГТИД омогућен на свим машинама у МиСКЛ кластеру; имамо омогућен ГТИД.
• Неопходно је да свуда постоји једна врста бинлогова, можете користити изјаву. Имали смо конфигурацију у којој су мастер и већина славе имали ред, а два су историјски остала у мешовитом режиму. Као резултат тога, Орцхестратор једноставно није желео да повеже ове славе са новим мастером.

Запамтите да је најважнија ствар у производном робу његова доследност са господаром! Ако имате омогућен Глобални ИД трансакције (ГТИД) и на главном и на славе-у, онда можете да користите функцију гтид_субсет да бисте сазнали да ли су исти захтеви за измене података заиста извршени на овим машинама. Можете прочитати више о овоме овде.

Дакле, Орцхестратор вам показује кроз грешку ГТИД да постоје трансакције на славе-у које нису на мастер-у. Зашто се ово дешава?

• Реад_онли=1 није омогућен на славе-у, неко се повезао и завршио захтев за промену података.
• Супер_реад_онли=1 није омогућен на славе-у, онда је администратор, збунивши сервер, ушао и тамо извршио захтев.
• Ако сте узели у обзир обе претходне тачке, онда постоји још један трик: у МиСКЛ-у, захтев за испирање бинлогова такође иде у бинлог, тако да ће се при првом испирању појавити грешка ГТИД-а на главном и свим славе-овима. Како то избећи? Перона-5.7.25-28 је увела бинлог_скип_флусх_цоммандс=1 поставку, која забрањује писање флусх-а у бинлогове. Постоји један успостављен на веб локацији мискл.цом буг.

Дозволите ми да сумирам све горе наведено. Ако још не желите да користите Орцхестратор у режиму преласка са грешке, онда га ставите у режим посматрања. Тада ћете увек имати пред очима мапу интеракције МиСКЛ машина и визуелне информације о томе какав је тип репликације на свакој машини, да ли робови заостају, и што је најважније, колико су доследни са мастер!

Очигледно питање је: „Како Оркестратор треба да ради?“ Он мора да изабере новог мастера од тренутних славе-ова, а затим поново повеже све славе-ове на њега (ово је оно за шта је потребан ГТИД; ако користите стари механизам са бинлог_наме и бинлог_пос, а затим пребаците славе са тренутног мастер на нови једноставно немогуће!). Пре него што смо имали Орцхестратор, једном сам све ово морао да радим ручно. Стари господар је висио због грешака Адаптец контролера; имао је око 10 робова. Морао сам да пренесем ВИП са главног на један од славе-а и поново повежем све остале славе на њега. Колико сам конзола морао да отворим, колико истовремених команди сам унео... Морао сам да сачекам до 3 сата ујутру, скинем оптерећење са свих славе-ова осим два, направим прву машину од две мастер, одмах прикључим другу машину на њега, тако да све остале робове прикључите новом господару и вратите терет. Генерално, страшно...

Како Орцхестратор ради када пређе у режим преласка са грешке? То се најлакше илуструје примером ситуације у којој желимо да од мајстора направимо моћнију, модернију машину него што имамо сада.

Слика приказује средину процеса. Шта је до сада већ урађено? Рекли смо да желимо да неки славе буде нови мастер, Оркестратор је почео да једноставно поново повезује све друге славе на њега, при чему је нови мастер деловао као транзитна машина. Са овом шемом нема грешака, сви славе раде, Орцхестратор уклања ВИП са старог мастера, преноси га на нови, прави реад_онли=0 и заборавља на стари мастер. Све! Застој наше услуге је време ВИП трансфера, које износи 2-3 секунде.

То је све за данас, хвала свима. Ускоро ће бити други чланак о Оркестратору. У чувеном совјетском филму „Гаража“, један лик је рекао: „Не бих ишао с њим у извиђање!“ Дакле, Оркестратору, ја бих ишао са тобом у извиђање!

Извор: ввв.хабр.цом