В тази серия блогове от три части въведохме рамка за висока достъпност (HA) за MySQL хостинг в част I и обсъдихме подробностите за полусинхронната репликация на MySQL в част II. Сега в част III разглеждаме как рамката се справя с някои от важните сценарии за отказ на MySQL и се възстановява, за да гарантира висока наличност.
Сценарии за отказ на MySQL
Сценарий 1 – Master MySQL пада
- Рамката Corosync и Pacemaker открива, че главният MySQL вече не е наличен. Pacemaker понижава главния ресурс и се опитва да се възстанови с рестартиране на услугата MySQL, ако е възможно.
- В този момент, поради полусинхронния характер на репликацията, всички транзакции, извършени на главния, са получени от поне един от подчинените.
- Пейсмейкърът изчаква, докато всички получени транзакции бъдат приложени към подчинените и позволява на подчинените да докладват своите резултати за повишение. Изчисляването на резултата се извършва по такъв начин, че резултатът е „0“, ако подчинен е напълно синхронизиран с главния, и е отрицателно число в противен случай.
- Пейсмейкърът избира подчинения, който е съобщил резултата 0, и повишава този подчинен, който сега поема ролята на главен MySQL, на който е разрешено записването.
- След повишение на подчинен, Resource Agent задейства модул за пренасочване на DNS. Модулът актуализира записа на прокси DNS с IP адреса на новия главен обект, като по този начин улеснява пренасочването на всички записвания на приложения към новия главен адрес.
- Пейсмейкърът също така настройва наличните подчинени устройства, за да започне репликиране от този нов главен.
По този начин, когато главен MySQL се повреди (независимо дали поради срив на MySQL, срив на ОС, рестартиране на системата и т.н.), нашата HA рамка го открива и насърчава подходящ подчинен на поемете ролята на господар. Това гарантира, че системата продължава да бъде достъпна за приложенията.
Обяснена рамка за висока достъпност #MySQL – част III:Сценарии на неуспех Щракнете, за да туитирате
Сценарий 2 – Подчинен MySQL пада
- Рамката Corosync и Pacemaker открива, че подчинения MySQL вече не е наличен.
- Пейсмейкърът се опитва да възстанови ресурса, като се опитва да рестартира MySQL на възела. Ако се появи, той се добавя обратно към текущия главен елемент като подчинен и репликацията продължава.
- Ако възстановяването не успее, Pacemaker отчита този ресурс като неизправен – въз основа на това, което сигнали или известия могат да бъдат генерирани. Ако е необходимо, екипът за поддръжка на ScaleGrid ще се справи с възстановяването на този възел.
- В този случай няма влияние върху наличността на MySQL услугите.
Сценарий 3 – Мрежов дял – Разпадане на мрежовата свързаност между главни и подчинени възли
Това е класически проблем във всяка разпределена система, при която всеки възел смята, че другите възли не работят, докато в действителност само мрежовата комуникация между възлите е нарушена. Този сценарий е по-известен като сценарий с разделен мозък и ако не се обработва правилно, може да доведе до повече от един възел, претендиращ за главен MySQL, което от своя страна води до несъответствия и корупция в данните.
Нека използваме пример, за да прегледаме как нашата рамка се справя със сценариите с разделен мозък в клъстера. Предполагаме, че поради проблеми с мрежата, клъстерът се е разделил на две групи – главен в едната група и 2 подчинени в другата група и ще означим това като [(M), (S1,S2)].
- Corosync открива, че главният възел не може да комуникира с подчинените възли и подчинените възли могат да комуникират помежду си, но не и с главния .
- Главният възел няма да може да извършва никакви транзакции, тъй като полусинхронната репликация очаква потвърждение от поне един от подчинените, преди главният да може да извърши ангажимент. В същото време Pacemaker изключва MySQL на главния възел поради липса на кворум въз основа на настройката на Pacemaker „no-quorum-policy =stop“. Кворум тук означава по-голямата част от възлите или два от три в настройка на клъстер с 3 възли. Тъй като има само един главен възел, работещ в този дял на клъстера, настройката за политика без кворум се задейства, което води до изключване на главния MySQL.
- Сега пейсмейкърът на дяла [(S1), (S2)] открива, че в клъстера няма наличен главен код и започва процес на повишение. Ако приемем, че S1 е актуален с главния (както се гарантира от полусинхронната репликация), тогава той се повишава като нов главен.
- Трафикът от приложението ще бъде пренасочен към този нов главен MySQL възел и подчиненият S2 ще започне да се репликира от новия главен.
Така виждаме, че рамката на MySQL HA се справя ефективно със сценарии с разделен мозък, като гарантира както последователност на данните, така и наличност в случай, че мрежовата свързаност се прекъсва между главни и подчинени възли.
Това завършва нашата серия от 3 части от блогове за MySQL High Availability (HA) рамка, използваща полусинхронна репликация и стека Corosync плюс Pacemaker. В ScaleGrid предлагаме високодостъпен хостинг за MySQL на AWS и MySQL на Azure, който се реализира въз основа на концепциите, обяснени в тази серия от блогове. Моля, посетете конзолата ScaleGrid за безплатна пробна версия на нашите решения.
