В част I въведохме рамка за висока достъпност (HA) за MySQL хостинг и обсъдихме различни компоненти и тяхната функционалност. Сега в част II ще обсъдим подробностите за полусинхронната репликация на MySQL и свързаните с нея конфигурационни настройки, които ни помагат да осигурим излишък и последователност на данните в нашата HA настройка. Не забравяйте да проверите отново за част III, където ще прегледаме различни сценарии на отказ, които могат да възникнат, и начина, по който рамката реагира и се възстановява от тези условия.
Какво е MySQL полусинхронна репликация?
Просто казано, в конфигурация за полусинхронна репликация на MySQL, главният извършва транзакции към механизма за съхранение само след като получи потвърждение от поне един от подчинените. Подчинените ще предоставят потвърждение само след като събитията бъдат получени и копирани в регистрационните файлове на релето, а също и прехвърлени на диска. Това гарантира, че за всички транзакции, извършени и върнати на клиента, данните съществуват на поне 2 възела. Терминът „полу“ в полусинхронно (репликация) се дължи на факта, че главният извършва транзакциите, след като събитията бъдат получени и прехвърлени в релейния дневник, но не е задължително да бъдат ангажирани с файловете с данни на подчинения. Това е в контраст с напълно синхронната репликация, при която транзакцията би била извършена както от подчинения, така и от главния, преди сесията да се върне към клиента.
Полусинхронната репликация, която е първоначално налична в MySQL, помага на рамката на HA да гарантира съгласуваност на данните и излишък за извършени транзакции. В случай на повреда на главния, всички транзакции, извършени на главния, биха били репликирани на поне един от подчинените (запазени в регистрационните файлове на релето). В резултат на това превключването към този подчинен елемент ще бъде без загуби, тъй като ведомото устройство е актуално (след като регистрите на релето на подчиненото устройство са напълно изтощени).
Настройки за репликация и полусинхронни свързани
Нека обсъдим някои от ключовите настройки на MySQL, използвани за осигуряване на оптимално поведение за висока наличност и последователност на данните в нашата рамка.
Управление на скоростта на изпълнение на подчинените
Първото съображение е да се обработи "полу" поведението на полусинхронната репликация, което гарантира само, че данните са получени и изхвърлени в регистрационните файлове на релето от I/O нишката на подчинен, но не е задължително ангажиран от SQL нишката. По подразбиране SQL нишката в MySQL slave е еднонишкова и няма да може да бъде в крак с главната, която е многонишкова. Очевидното въздействие от това е, че в случай на повреда на главната, подчинената няма да бъде актуална, тъй като нейната SQL нишка все още обработва събитията в регистъра на релето. Това ще забави процеса на отказ, тъй като нашата рамка очаква подчинения да бъде напълно актуален, преди да може да бъде повишен. Това е необходимо, за да се запази последователността на данните. За да разрешим този проблем, ние разрешаваме многонишкови подчинени устройства с опцията slave_parallel_workers, за да зададем броя на паралелните SQL нишки за обработка на събития в регистрационните файлове на релето.
В допълнение, ние конфигурираме настройките по-долу, които гарантират, че ведомото устройство не влиза в състояние, в което главният не е бил:
- slave-parallel-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Това ни осигурява по-силна последователност на данните. С тези настройки ще можем да постигнем по-добра паралелизация и скорост на подчинения, но ако има твърде много паралелни нишки, режийните разходи, свързани с координирането между нишките, също ще се увеличат и за съжаление могат да компенсират ползите.
Друга конфигурация, която можем да използваме, за да увеличим ефективността на паралелното изпълнение на подчинените, е да настроим binlog_group_commit_sync_delay на главния. Като зададете това на главен, бинарните записи в регистрационния файл на главния и следователно записите в релейния дневник на подчинения ще имат партиди транзакции, които могат да се обработват паралелно от SQL нишките. Това е обяснено подробно в блога на J-F Gagné, където той нарича това поведение като „забавяне на господаря, за да се ускори подчинения“ .
Ако управлявате внедряванията на MySQL през конзолата ScaleGrid, имате възможността непрекъснато да наблюдавате и получавате сигнали в реално време за забавянето на репликацията на подчинените. Той също така ви позволява динамично да настройвате горните параметри, за да гарантирате, че подчинените работят ръка за ръка с главния, като по този начин минимизирате времето ви, участващо в процеса на отказ.
Обяснение на MySQL High Availability Framework - Част IICЩракнете за Tweet
Важни опции за полусинхронна репликация
Полусинхронната репликация на MySQL, по проект, може да се върне обратно към асинхронен режим въз основа на настройките за изчакване на потвърждение на подчинен или въз основа на броя на наличните подчинени устройства с възможност за полусинхронно във всеки момент. Асинхронният режим по дефиниция не осигурява гаранции, че ангажиментите транзакции се репликират на подчинения и следователно загубата на главен източник би довела до загуба на данни, които не са били репликирани. Дизайнът по подразбиране на рамката на ScaleGrid HA е да се избегне връщането към асинхронен режим. Нека прегледаме конфигурациите, които влияят на това поведение.
-
rpl_semi_sync_master_wait_for_slave_count
Тази опция се използва за конфигуриране на броя на подчинените, които трябва да изпратят потвърждение, преди полусинхронен главен да може да извърши транзакцията. В конфигурацията главен-подчинен с 3 възела ние задаваме това на 1, така че винаги да имаме увереност, че данните са налични в поне един подчинен, като същевременно избягваме всякакво въздействие върху производителността, свързано с изчакване на потвърждение от двете подчинени устройства.
-
rpl_semi_sync_master_timeout
Тази опция се използва за конфигуриране на времето, през което полусинхронният главен оператор чака потвърждение от подчинен, преди да се върне обратно в асинхронен режим. Задаваме това на относително висока стойност на изчакване, така че да няма връщане към асинхронен режим.
Тъй като работим с 2 подчинени и rpl_semi_sync_master_wait_for_slave_count е настроен на 1, забелязахме, че поне един от подчинените потвърждава в рамките на разумен период от време и главният не преминава в асинхронен режим по време на временни прекъсвания на мрежата.
-
rpl_semi_sync_master_wait_no_slave
Това контролира дали главният изчаква периода на изчакване, конфигуриран от rpl_semi_sync_master_timeout, да изтече, дори ако броят на подчинените падне до по-малко от броя на подчинените, конфигурирани от rpl_semi_sync_master_wait_for_slave_count през периода на изчакване. Запазваме стойността по подразбиране на ON, така че главната програма да не се върне към асинхронна репликация.
Въздействие от загубата на всички полусинхронни роби
Както видяхме по-горе, нашата рамка предотвратява превключването на главната към асинхронна репликация, ако всички подчинени устройства изпаднат или станат недостъпни от главната. Прякото въздействие на това е, че записите се спират върху главния, което влияе върху наличността на услугата. Това по същество е както е описано от теоремата на CAP за ограниченията на всяка разпределена система. Теоремата гласи, че при наличието на мрежов дял ще трябва да изберем или наличност, или последователност, но не и двете. Мрежовият дял в този случай може да се счита за подчинени MySQL устройства, които са изключени от главния, защото са или неактивни, или недостъпни.
Нашата цел за последователност е да гарантираме, че за всички ангажирани транзакции данните са налични на поне 2 възела. В резултат на това в такива случаи рамката на ScaleGrid HA предпочита последователността пред наличността. По-нататъшни записи няма да се приемат от клиенти, въпреки че главният MySQL все още ще обслужва заявките за четене. Това е съзнателно дизайнерско решение, което сме взели като поведение по подразбиране, което, разбира се, може да се конфигурира въз основа на изискванията на приложението.
Не забравяйте да се абонирате за блога на ScaleGrid, за да не пропуснете част III, където ще обсъдим повече сценарии за отказ и възможности за възстановяване на рамката на MySQL HA . Останете на линия!!
